Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Elinating the 'rx' from AREXX Message-ID:Date: 13 Aug 89 12:19:59 GMT References: <1989Aug8.214011.3351@agate.berkeley.edu> <479@tw-rnd.SanDiego.NCR.COM> <89222.093949UH2@PSUVM> <19146@usc.edu> <276@nlgvax.UUCP> Sender: usenet@rpi.edu Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 76 In-reply-to: hans@nlgvax.UUCP's message of 13 Aug 89 09:48:49 GMT addison@pollux.usc.edu (Richard Addison) writes: Richard> If I remember correctly, /bin/sh is the default shell for Richard> executing scripts unless another shell is specified on the Richard> first line. Yep. On 13 Aug 89 09:48:49 GMT, hans@nlgvax.UUCP (Hans Zuidam) said: Hans> Nope. And nope back to you. Hans> A UNIX shell looks at the first two bytes of the file you try to Hans> execute. [...] When the magic word is not that of a code Hans> (executable) file the exec call to the kernel will fail and the Hans> current shell assumes the file is a script and tries to Hans> interpret it accordingly. Try this by executing a Sun binary on Hans> a VAX or vice versa. You will get a syntax error from the shell. FALSE. If the magic number does not match, and there is no #! interpreter specified, the exec call assumes /bin/sh as an interpreter. The syntax errors you get are bourne shell errors, from the shell execve() created, NOT your current shell. For example, if you have a csh shell script, and are using csh, executing the csh script will try to interpret it with sh unless you begin the file with "#!/bin/csh". Only typing "source " will make the current shell execute the commands. Hans> Now the '#!' combination is a BSD special. It is documented Hans> nowhere (at least the last time I looked 2 years ago ;-) ). When Hans> the first two characters of a file passed to the loader are Hans> '#!', the *loader* takes everything upto the fist newline as the Hans> name of an executable to pass the rest of the file to. The Hans> executable is started and the current file is passed on its Hans> standard input. Under SunOS, #! is documented in the execve(2) man page. The "loader" is part of the execve() system call. It takes an interpreter path, optional args, tacks on the argv[0] filename of the script, and sets stdin to the script as well. If no magic number matches, and no interpreter is specified, it assumes /bin/sh and continues. Hans> In my humble opinion this is not how the Amiga should do it. In my opinion, this IS how the Amiga should do it. Hans> The Amiga way of doing things would be to have a separate Hans> process for each loader format, just as there is a separate task Hans> for each device instantation, for each (2 :-) ) file system and Hans> so on. You are a sick puppy. [:-)] Hans> A much more opener design would be to have a hierarchy of Hans> loaders with one master which knows how to scatter load Hans> segments. If it couldn't load a file (because it is not an Hans> executable) it would pass the file on to the next in the chain. A linked list of possible loading functions makes sense. A task for each is absurd. Hans> On the Amiga running down lists is quite ok. Exec's doubly-linked lists are efficient, dynamic and flexible. But this isn't relevant to #! and interpreters. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.