17 Dec
2011
17 Dec
'11
9:05 a.m.
On 17/12/11 11:13 AM, Holm Tiffe wrote:
Yes, that more-or-less happens in those cases (GUIs and executables run
Toby Thain wrote:
You are right about that mechanism in shell, for executables.
But I was thinking about user files. There's no corresponding mechanism
in traditional non-GUI Unix (GUIs usually add one).
On 16/12/11 11:43 AM, Holm Tiffe wrote:
How do you think an unix shell is starting an excecutable file and trough
wich mechanism it knows what todo with an perl script, an shell script, an
C-shell scipt, and different kinds of executable binary formats?
It looks in the file for its header and is starting the correct command
interpreter for running that file or set up the environment for executing a
binary executable.
In unix a shell is doing this, so the guy above with it's CP/M hint is
really right here. Cameron Kaiser wrote:
Unix traditionally *doesn't* do that either. > Extensions are extensions. All the above is
just interpretation. File
> association is not rocket science (though it's been reinvented too many
> times). The interesting exception is classic MacOS with its type/creator
> codes independent of extension (and where extensions were initially
> absent, though like Unix, supported as part of the file name).
I have always loved type/creator codes, and was very unhappy with Apple
for
removing them in 10.6 (but I'm 10.4 forever, so I guess it's not really my
concern).
The gap was that the core OS did not provide an easy way to manipulate
this
consistently, requiring a cavalcade of minitools (or a trip to ResEdit) to
set them the way you wanted. But I loved being able to force certain
files to
automatically open in different apps if I wanted to, and at least for a
time
OS X gave you the choice.
--
------------------------------------ personal:
http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com *
ckaiser at floodgap.com
-- Nothing recedes like success. -- Walter Winchell
---------------------------
OS X is not Unix in this case and Unix never ever decided what to do with a
file by its extension but t does by its magic number (look for /etc/magic).
Automatic file associations are a post-GUI idea, in general, to my
recollection. Traditionally in Unix you can apply any program to any
file. It may or may not sniff! It may or may not crash. etc. :)
It is pretty hard on the traditional Unix command line to say: "open
this file with whatever program can deal with it". [OS X has such a
command; I think GNOME does; but again: post-GUI.]
(I am aware of 'file', but that doesn't, to me, do what you're
suggesting.)
Where is the file extension of this file and which one is to be used for
that what you want?
Files should have an header wich describes what type of data the file
represents. An Handler in the OS or one of the user shells (if Gui or not)
could decide this way what todo with it regarding the capabilities that the
concrete environment actually has.
BTW:
touch what.the.heck.for.an.ext.tension.do.you.mean.?
$ ls -l what*
-rw-r--r-- 1 holm holm 0 16 Dez 17:40
what.the.heck.for.an.ext.tension.do.you.mean.?
$ rm what*
$
I'm not sure what this is meant to illustrate? from shell).
But it *doesn't* happen elsewhere in Unix (e.g. for non-executable files).
--T
This is exactly what the /etc/magic mechanism is doing.
Regards,
Holm