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 [EMAIL PROTECTED]
