jtc@tessera.UUCP (J.T. Conklin) (09/06/88)
Has anyone patched the kernel exec routine to execute interpreter
files ("#!" scripts)?
I'm holding back the urge to dissassemble until I'm sure it hasn't
been done before.
If it hasn't been done, would anyone be interested in it when I
finish?
Thanks,
--jtc
--
J.T. Conklin (..!ubc-cs!fornax!syssol!seacbc!tessera!jtc)
4831 Hickory Court, Burnaby, B.C Canada
(604) 435-9458rosso@sco.COM (Ross Oliver) (09/12/88)
In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >Has anyone patched the kernel exec routine to execute interpreter >files ("#!" scripts)? The exec() function executes binaries only. If exec() fails (which it does on a shell script), then it is up to your shell to decide what to do. The Bourne shell then executes "sh <file>" The C shell will look at the first line, and if it starts with "#!", csh executes the script as "csh <file>", otherwise, it uses "sh <file>" The Bourne shell, of course, assumes everything that is not a binary is a Bourne shell script. Ross Oliver SCO Technical Support uunet!sco!rosso
haugj@pigs.UUCP (The Beach Bum) (09/13/88)
In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >Has anyone patched the kernel exec routine to execute interpreter >files ("#!" scripts)? none that i know of. i don't think it would be too hard for someone with the source (SCO: hint, hint). >I'm holding back the urge to dissassemble until I'm sure it hasn't >been done before. you will also have to dissassemble quite a few other routines because exec() is in a file with a few other routines. >If it hasn't been done, would anyone be interested in it when I >finish? i'd be interested if SCO or whoever didn't mind. what you are suggesting is highly illegal so i don't think a posting is in order ;-) -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
haugj@pigs.UUCP (The Beach Bum) (09/13/88)
In article <858@viscous> rosso@sco.COM (Ross Oliver) writes: >In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >>Has anyone patched the kernel exec routine to execute interpreter >>files ("#!" scripts)? > >The exec() function executes binaries only. If exec() fails (which >it does on a shell script), then it is up to your shell to decide >what to do. [ this process has been described in the past. it was something which ken thompson (?) added to the research kernel years ago. ] there are unix systems where exec() in the kernel knows about shell scripts. the magic number #! (one of 021441 or 020443) is trapped by the kernel, which then scans the rest of the line from the executable file. the remainder of the line (which is going to be a binary executable) is then used in place of the first argument to exec. an exec call of the form execlp ("myscript", "myscript", "arg", 0); gets converted internally, after seeing '#! /usr/lbin/perl' say, to execlp ("/usr/lbin/perl", "myscript", "myscript", "arg", 0); [ this is from faulty memory. the second argument may become the interpreter name as well. ] the first block of the executable is read in and checked for magic numbers so all of this can be dealt with before the argument list is constructed for the new task. it really would be best if sco added this feature. fork(), exit() and sbrk() are in the same file (os/sys1.c) [ run nm(1) on your libraries for more information ] as exec(). you do not want to disassemble that much code and then expect the result to work ;-) -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
fyl@ssc.UUCP (Phil Hughes) (09/15/88)
In article <858@viscous>, rosso@sco.COM (Ross Oliver) writes: | In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: | >Has anyone patched the kernel exec routine to execute interpreter | >files ("#!" scripts)? | | The exec() function executes binaries only. If exec() fails (which | it does on a shell script), then it is up to your shell to decide | what to do. The Bourne shell then executes "sh <file>" The C shell | will look at the first line, and if it starts with "#!", csh executes | the script as "csh <file>", otherwise, it uses "sh <file>" The | Bourne shell, of course, assumes everything that is not a binary is | a Bourne shell script. | | Ross Oliver | SCO Technical Support | uunet!sco!rosso I take it to mean that, at least, SCO hasn't. Also, csh only looks for the #, not #! on SCO XENIX (or any other system for that matter). -- Phil uunet!pilchuck!ssc!fyl
markz@ssc.UUCP (Mark Zenier) (09/16/88)
In article <405@pigs.UUCP>, haugj@pigs.UUCP (The Beach Bum) writes: > In article <858@viscous> rosso@sco.COM (Ross Oliver) writes: > >In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: > >>Has anyone patched the kernel exec routine to execute interpreter > >>files ("#!" scripts)? > > > >The exec() function executes binaries only. If exec() fails (which > >it does on a shell script), then it is up to your shell to decide > >what to do. > Isn't the shell script check implemented in the library routine that is linked in, and not the kernel. This is what Rochkind says in "Advanced Unix Programming". This sounds much easier than disassembling half of the kernel. Mark Zenier uunet!pilchuck!ssc!markz "He did decide, though, that with more time and a great deal of mental effort, he could probably turn the activity into an acceptable perversion"-Mick Farren
haugj@pigs.UUCP (The Beach Bum) (09/17/88)
In article <1459@ssc.UUCP> markz@ssc.UUCP (Mark Zenier) writes: >Isn't the shell script check implemented in the library routine that >is linked in, and not the kernel. This is what Rochkind says in >"Advanced Unix Programming". This sounds much easier than disassembling >half of the kernel. it depends. on some systems the '#!' hack is part of the C library. on others, it is in the kernel. the actually hack is so simple that it can be added in one afternoon of work. i'd guess [ in case ross wants to added it to xenix 2.4 ;-) ] the best place to start is in gethead(). just look for the appropriate magic number [ see the previous posting by my ], then jump off and get the program name since the block has already by read [ there should be a bread() in gethead() - add an extra field to the x.out header for the program name or something ... ] and we are only talking about disassembling 2000 lines of assembler or so. shouldn't take more than 3 or 4 days to produce C code from that ;-) -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
woods@gpu.utcs.toronto.edu (Greg Woods) (09/19/88)
In article <1458@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >In article <858@viscous>, rosso@sco.COM (Ross Oliver) writes: >| In article <161@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >| >Has anyone patched the kernel exec routine to execute interpreter >| >files ("#!" scripts)? > >I take it to mean that, at least, SCO hasn't. >Also, csh only looks for the #, not #! on SCO XENIX (or any other >system for that matter). Alas, they certainly hadn't fixed either csh, or exec(), last time I used Xenix. The csh port done by ISC for 386/ix is a little more mature. It does invoke the correct command interpreter if necessary. This is all fine and dandy if _everyone_ on your system uses csh. However, I find it simply ludicrous that the "#!" fix hasn't been done to any recent, common, implementations of Unix, other than BSD. Though I don't have the most recent POSIX draft (only Draft 10), it seems that POSIX won't make this fix mandatory either. Anyone have any remarks on what might be, or is being, done about this feature in the so called SysV-BSD merger? Will this affect POSIX? On another note, ISC also did a fairly reasonable simulation of job control too. They didn't use SXT's, so ^Z doesn't work, and fg doesn't either. SysV's lack of proper process group semantics is also a pain. However, 'jobs' does show background tasks, 'kill %n' works, and 'set notify' even works. To continue my questions: Does anyone know what may be done about proper job control in the merged SysV-BSD stuff? I see SIGSTOP and friends, as well as better process group semantics as necessary. Shl just doesn't cut it (nor does layers, though it is better). -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada