On Mon, Jan 03, 2000 at 02:16:16PM +0100, Niels Möller wrote:
> I suspect Debian's update-alternative suck the same way as the global
> file <-> tool mapping on the Amiga. System level defaults is the wrong
> way to handle user preferences (if I have misunderstood what
> update-alternatives does, p
Adam Sampson <[EMAIL PROTECTED]> writes:
> Just as a contrast, the Amiga Workbench stores a number of useful file
> attributes inside a ".info" file, including the icon, whether the
> file was a program or a "project" (data file), and if it was a project what
> program to load it with when it was
On Thu, Dec 30, 1999 at 01:10:51PM -0900, George A. Dowding wrote:
> * Obligatory Random Idea:
>
> Has anyone taken a look at Plan 9/Inferno. They have made some
> interesting design decisions. One of the most interesting is to
> elevate the concept of files. Not only are all p
On Thu, Dec 30, 1999 at 01:10:51PM -0900, George A. Dowding wrote:
> Greetings,
>
> * Obligatory Random Idea:
>
> Has anyone taken a look at Plan 9/Inferno. They have made some
> interesting design decisions. One of the most interesting is to
> elevate the concept of fil
On Wed, Dec 29, 1999 at 05:40:04PM -0800, Mark Lundeberg wrote:
> Using #! wouldn't be a very good solution. You could solve the path
> problem and make it user-configurable hacking the #! header interpreter to
> take something like '#!text-editor' or '#!gz-uncompress', so it could be
> user-config
On Wed, Dec 29, 1999 at 12:30:14PM -0500, Thomas Bushnell, BSG wrote:
> > 1) In the same manner of transparent ftp, we can have transparent http =
> > to get web pages we need (cd /www/www.gnu.org/hurd) and maybe even =
> > something like cd /www/www.google.com/search?q=3Dgnu
>
> Yes, but I'd like
On Thu, Dec 30, 1999 at 01:27:27AM +, Adam Sampson wrote:
> (The script's attached; it's a quick wrapper around tar, gzip and bzip2,
> handling multiple archives, letting you do "tart x firstfile.tar.gz
> secondfile.tar thirdfile.tar.bz2" etc.)
D'oh! Forgot to insert the script... here it is.
Hello Adam Sampson!
On Thu, 30 December 1999 at 01:27:27, you wrote:
> foo.xbm -> image/xbm
> foo.xbm.gz -> encode/gzip:image/xbm
> foo.xbm.bz2.uu -> encode/uu:encode/bzip2:image/xbm
See "http://www.tuxedo.org/~esr/magic-numbers/"; - seems like
this could
On Thu, Dec 30, 1999 at 03:23:12AM +0100, Dirk Ritter wrote:
> - types would need to be determined from the data alone so
> that foo.txt would be clearly identifiable as X-Bitmap if
> foo.txt's data is a valid X-Bitmap - but what are you going
> to do about foo.txt.gz?
One of the most useful
> "Dirk" == Dirk Ritter <[EMAIL PROTECTED]> writes:
This is just my two cents:
>> 2) Add mime types to the file information in the file
>> system. This will make the file command trivial, and will allow
>> some pretty neat things to be done (like writing a program that
>> will
probably not a good idea to
clutter up a file system with extra information that may or may not be
used. After all the main purpose of a file system should be the
efficient storage and recall of data whatever its content may be.
* Obligatory Random Idea:
Has anyone taken a look at Plan 9/Inferno. They
I seem to have rambled on a bit here, but anway...
On Thu, 30 Dec 1999, Dirk Ritter wrote:
> I guess roughly the same goes for OS/2 with the notable exception that
> it did not depend solely on those *.foo.bar extensions.
Actually, I rather liked the way OS/2 worked like that. Granted, it
worke
Dirk Ritter <[EMAIL PROTECTED]> writes:
> Hello chen!
>
> On Thu, 30 December 1999 at 08:51:19, you wrote:
> >
> > The program creating the file can record the file type when creating it.
> > There can be a default file type umask
>
> Looks reasonable but I doubt that it works without probl
Hello Mark Lundeberg!
On Wed, 29 December 1999 at 17:40:04, you wrote:
>
> Using #! wouldn't be a very good solution.
Of course.
> A nice solution would be nearly like W95's system for executing files,
> except using the 'file' command (or something similar that returns a MIME
> type) to
Hello chen!
On Thu, 30 December 1999 at 08:51:19, you wrote:
>
> The program creating the file can record the file type when creating it.
> There can be a default file type umask
Looks reasonable but I doubt that it works without problems.
Too simple and much too weak if you ask me.
> It c
Hello Marcus Brinkmann!
On Thu, 30 December 1999 at 15:35:31, you wrote:
>
> If every user can start her own exec server with the features she wants,
> it's not a core OS component anymore.
That's the trick - users may replace them but I still would regard
them as 'essentials'. (Of course -
On Thu, Dec 30, 1999 at 03:23:12AM +0100, Dirk Ritter wrote:
> do you still feel that it
> is beneficial to offer such functionality inside core OS components
> such as file systems or exec servers? I doubt it.
If every user can start her own exec server with the features she wants,
it's not a cor
> Mark Lundeberg <[EMAIL PROTECTED]> writes:
>
> > [mime types and associated actions]
>
> This is fully implemented in GNOME.
Yeah, what I was suggested is to make life easier for gnome (no more
guessing games!), and make this type of action association avaliable for
shell scripts.
Thanks!
Ch
> This of course seems like a nice idea, but it has some pitfalls:
> - file systems would need to generate this information "on the fly"
Actually my idea was that the file system would *keep* the mime type with
the rest of the information (permissions and so) and use it. The question is
ofcourse
Mark Lundeberg <[EMAIL PROTECTED]> writes:
> [mime types and associated actions]
This is fully implemented in GNOME.
--
Colin Walters <[EMAIL PROTECTED]>
http://web.verbum.org/levanti
(1024D/C207843A) A580 5AA1 0887 2032 7EFB 19F4 9776 6282 C207 843A
On Thu, 30 Dec 1999, Dirk Ritter wrote:
> This leads me to a final question - maybe you want your shell's
> interpreter hack to decide what interpreter to run based on the
> file type? Of course - text files can be made executable and if
> you write '#/bin/emacs' in the first line you will be abl
Hello Chen Shapira!
> 2) Add mime types to the file information in the file system. This will
> make the file command trivial, and will allow some pretty neat things to
> be done (like writing a program that will act differently depends on the
> file type. "run $1" that will open gimp for grap
On Wed, 29 Dec 1999, chen wrote:
> 1) In the same manner of transparent ftp, we can have transparent http
> to get web pages we need (cd /www/www.gnu.org/hurd) and maybe even
> something like cd /www/www.google.com/search?q=gnu
A problem with transparent http is that many servers have a page to
"chen" <[EMAIL PROTECTED]> writes:
> 1) In the same manner of transparent ftp, we can have transparent http =
> to get web pages we need (cd /www/www.gnu.org/hurd) and maybe even =
> something like cd /www/www.google.com/search?q=3Dgnu
Yes, but I'd like a transparent http node to be labelled "htt
Hi,
Just thought of 2 ideas, tell me what you guys
think...
1) In the same manner of transparent ftp, we can
have transparent http to get web pages we need (cd /www/www.gnu.org/hurd) and
maybe even something like cd /www/www.google.com/search?q=gnu
2) Add mime types to the file inform
25 matches
Mail list logo
