Re: Random idea:
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 scripts (to me, anyway) I've written has to solve
this problem; it handles compressed files by remembering that the file is
compressed, uncompressing it and checking the type. (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.) I see no reason why a "libmagic" shouldn't use this approach, perhaps
returning a list of filetypes, e.g.
foo.xbm -> image/xbm
foo.xbm.gz -> encode/gzip:image/xbm
foo.xbm.bz2.uu -> encode/uu:encode/bzip2:image/xbm
I see no reason to put this into kernelspace (hmm, serverspace?).
> The Workplace shell used to store icons inside those attributes,
> but I don't see how anyone would benefit from that since this
> way you end up with lots of duplicated bitmap data - a waste of
> space and resources and maybe it even gets in the way occasionally,
> perhaps if kids want to replace their old icons with new, cute
> looking 3-D like icons.
Just as a contrast, the Amiga Workbench stores a number of useful file
attributes inside a "<filename>.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 run, and a list of "tooltypes" (string
attributes), which the OS ignored but can be read by applications, meaning
that small programs don't need a config file---they just read their
configuration data out of their .info file (via an API routine).
The Acorn RiscOS, on the other hand, just gives each filesystem entry a
"file type" attribute, a 3-digit hex number, which is magically translated
into an icon and the program to load the file with by the OS. Programs don't
use this mechanism, as a program (whose name is always prefixed by a !) is
really a directory, containing a number of files to be loaded into memory
and executed. (Yes, I think it's weird too.)
> Of course - text files can be made executable and if you write
> '#/bin/emacs' in the first line you will be able to start emacs and load
> the file you want to edit. This is ugly since it will break under
> GNU/Linux where emacs is under '/usr/bin' [...]
On a different tack, why couldn't #! execution look at the user's path? It
would be much nicer to be able to write:
#!python
rather than
#!/usr/local/bin/python
And yes, I know about /usr/bin/env, thank you. I'd just like to see ths OS
doing it for me. I don't think it's a security issue, as suid scripts aren't
allowed.
--
Adam Sampson
azz@gnu.org
Reply to: