jhc@mtune.ATT.COM (Jonathan Clark) (06/21/87)
Keywords: Listen guys, if I say 'cd a/b/c/d/e;cd ..' then I am now in a/b/c/d, regardless of how many symlinks or networked file systems I had to go through to get there. Anything else is brain-damaged. On a similar note, for the people who are expounding starting one's shell scripts with "#! /bin/csh", the logical continuation of this is to start one's C programs with "#! /bin/cc", and so on. Writing a language processor which is a partial superset of an existing standard is one thing, and quite OK in my book; hacking the kernel to support this automagically is quite another. Perhaps csh should have been made to interpret a strict superset of the Bourne shell, so that normal scripts work under it, and then csh scripts should have been interpreted via "csh script"? Then we wouldn't have this problem. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy%gorodish@Sun.COM (Guy Harris) (06/22/87)
> Listen guys, if I say 'cd a/b/c/d/e;cd ..' then I am now in a/b/c/d, > regardless of how many symlinks or networked file systems I had to go > through to get there. Anything else is brain-damaged. Which can, in most cases, be done by the shell interpreting the "cd" command; the question is whether one should add extra stuff to the kernel to make this work invisibly? I tend to agree with what was given as Dennis Ritchie's position, which was "no". > On a similar note, for the people who are expounding starting one's > shell scripts with "#! /bin/csh", the logical continuation of this is > to start one's C programs with "#! /bin/cc", and so on. No. Executable files begin with a magic number, which indicates the interpreter to be used to execute that file. The "conventional" magic numbers indicate that the interpreter in question is the machine's hardware (including microcode if you have it); the "#!" magic number selects a program to be used as the interpreter. One would start C programs with "#! /usr/bin/c_interpreter" or something like that; unless one has a C interpreter, one does not normally execute C code. The intent behind "#!" was to permit *arbitrary* interpreters to run programs, not just shells. (It also permits interpreted programs to be set-UID, assuming you trust the interpreter's mechanisms to the degree necessary to make set-UID interpeted programs safe. Prior to 4.3BSD, there were two very large security holes that rendered set-UID shell scripts, at least, unsafe; those two holes were closed in 4.3BSD, but there could well be others.) > Writing a language processor which is a partial superset of an existing > standard is one thing, and quite OK in my book; hacking the kernel to > support this automagically is quite another. Huh? How does "#!" "automagically" support "...a language processor which is a partial superset of an existing standard"? What it supports is executing shell scripts as ordinary programs *without* having to ensure that all programs that might try to execute that script use "exec[lv]p" instead of "exec[lv]". The latter is somewhat nice, considering that not all programs *do* use "exec[lv]p". > Perhaps csh should have been made to interpret a strict superset of the > Bourne shell, Considering that the C shell, I believe, antedated the Bourne shell (or, at least, the public availability of the Bourne shell), this might not have been practical. > so that normal scripts work under it, and then csh scripts should have > been interpreted via "csh script"? Then we wouldn't have this problem. "#!" was not concocted merely to solve the C shell vs. Bourne shell problem. I presume DMR came up with it as a nice generalization of the notion of "executable image" and "magic number"; the cost in terms of kernel code is small, and the benefits seem to outweigh them. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
m5@bobkat.UUCP (Mike McNally ) (06/24/87)
In article <1097@mtune.ATT.COM> jhc@mtune.UUCP (Jonathan Clark) writes: >Listen guys, if I say 'cd a/b/c/d/e;cd ..' then I am now in a/b/c/d, >regardless of how many symlinks or networked file systems I had to go >through to get there. Anything else is brain-damaged. Well gee, if I cd to somewhere and then cd to .., I expect my current directory to be changed to the parent of the previous wd. I have never been confused by this, and I'm amazed at the amount of people who are. > >On a similar note, for the people who are expounding starting one's >shell scripts with "#! /bin/csh", the logical continuation of this is >to start one's C programs with "#! /bin/cc", and so on. Wow, on my system I have to compile my C programs. This process results in an executable file with (guess what) a magic number at the beginning. > Writing a >language processor which is a partial superset of an existing standard >is one thing, and quite OK in my book; hacking the kernel to support this >automagically is quite another. The kernel supports *any* interpreter. I can start a makefile with #!/bin/make and that will work; I can start an awk script with #!/bin/awk and that will work; I can put #!sort at the top of a file, change its mode, then run it to see the sorted contents. And of course, I can start a C sourcefile with #!/bin/cc and then run it to invoke the compiler (which will complain about the illegal preprocessor command, I think). The #! "hack" was not just for csh. > Perhaps csh should have been made to >interpret a strict superset of the Bourne shell, so that normal scripts >work under it, and then csh scripts should have been interpreted via >"csh script"? Then we wouldn't have this problem. Please. There is more to running programs than what is typed from a shell. What about other programs that want to run somthing via execve? Are they supposed to figure out what interpreter to use by calling "file"??? >Jonathan Clark >[NAC,attmail]!mtune!jhc -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
simon@its63b.ed.ac.uk (Simon Brown) (06/25/87)
In article <21681@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >The intent behind "#!" was to permit *arbitrary* interpreters to run >programs, not just shells. (It also permits interpreted programs to >be set-UID, assuming you trust the interpreter's mechanisms to the >degree necessary to make set-UID interpeted programs safe. Prior to >4.3BSD, there were two very large security holes that rendered >set-UID shell scripts, at least, unsafe; those two holes were closed >in 4.3BSD, but there could well be others.) > >Huh? How does "#!" "automagically" support "...a language processor >which is a partial superset of an existing standard"? What it >supports is executing shell scripts as ordinary programs *without* >having to ensure that all programs that might try to execute that >script use "exec[lv]p" instead of "exec[lv]". The latter is somewhat >nice, considering that not all programs *do* use "exec[lv]p". > Unfortunately, execution of a "program" only makes sense from within an interpreter environment (such as sh, csh, ...). After all, the command "/bin/cat" that gets executed by a "#!/bin/cat" interpreter could have widely different interpretations depending on who is executing it. Luckily, all shells treat pathname-commands as being "execv that pathname", but this does limit the sort of commands that may be issued via a #! directive. I would quite like to use pipes, i/o redirection, shell-variables, etc... in a #! - for example #!(sed 1d | tbl | nroff -ms | lpr) .PP Hello. .TS a table .TE [etc...] in a file, to automatically run its contents through "tbl" and "nroff" and print out the result, whenever the file is executed. But there is no provision for this sort of syntax in a #!, which is a pity. I guess ``#!/bin/sh -c "sed -d $1 | tbl | nroff -ms | lpr"'' might work, but this is very ugly. %{ Simon. %} -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!its63b!simon | Department of Computer Science | JANET: simon@uk.ac.ed.its63b | University of Edinburgh, | ARPA: simon%its63b.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | ---------------------------------- "Life's like that, you know"
chris@mimsy.UUCP (Chris Torek) (07/05/87)
In article <500@its63b.ed.ac.uk> simon@its63b.ed.ac.uk (Simon Brown) writes: >I would quite like to use pipes, i/o redirection, shell-variables, etc... in >a #! - for example > #!(sed 1d | tbl | nroff -ms | lpr) > .PP > Hello. > .TS > a table > .TE > [etc...] `#!' is supposed to be *simple*. . . ! >I guess ``#!/bin/sh -c "sed -d $1 | tbl | nroff -ms | lpr"'' might work, No, because `#!' can create at most one argument, so this would pass the string "-c \"sed -d $1 | tbl | nroff -ms | lpr\"" (in C notation) to /bin/sh. What will work is this: #! /bin/sh tbl << '*end*of*text*' | nroff -ms | lpr .PP Hello. ... *end*of*text* -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
guy%gorodish@Sun.COM (Guy Harris) (07/05/87)
> Unfortunately, execution of a "program" only makes sense from within an > interpreter environment (such as sh, csh, ...). After all, the command > "/bin/cat" that gets executed by a "#!/bin/cat" interpreter could have > widely different interpretations depending on who is executing it. What? You don't have to be a shell to execute a program, so I don't see where an "interpreter environment" comes into it. "init" and "login" aren't interpreters in any commonly understood sense of the word (perhaps in a trivial sense, but that's it), and they execute plenty of programs. Furthermore, there is only one interepreter that's *supposed* to execute "/bin/cat", and that's the one implemented by the hardware, microcode, and supporting software (kernel, etc.) on your machine. Yes, if you treat "/bin/cat" as a shell script it will have a different (and probably not very interesting) interpretation, but so what? > I would quite like to use pipes, i/o redirection, shell-variables, etc... in > a #! It's not clear that generalizing "#!" so that the interpreter it executes is an arbitrary shell command or pipeline, and not just a single program, would be worth the costs. It would require hardcoding either information about the command syntax of some particular shell into the kernel, or hardcoding rules telling it to run the command line in question through a particular shell or shells into the kernel. Both would increase the complexity of the implementation, and hardwire things that shouldn't be hardwired. Furthermore, it would mean that "execve" and company would not be guaranteed only to change the image running in the current process; they would have to fiddle the file descriptors of that process, spawn new processes, etc., etc., etc.. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
allbery@ncoast.UUCP (07/06/87)
As quoted from <7330@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek): +--------------- | In article <500@its63b.ed.ac.uk> simon@its63b.ed.ac.uk (Simon Brown) writes: | >I would quite like to use pipes, i/o redirection, shell-variables, etc... in | >a #! - for example | >I guess ``#!/bin/sh -c "sed -d $1 | tbl | nroff -ms | lpr"'' might work, | | No, because `#!' can create at most one argument, so this would | pass the string "-c \"sed -d $1 | tbl | nroff -ms | lpr\"" (in C | notation) to /bin/sh. What will work is this: +--------------- Has anyone considered writing a program which exec's /bin/sh with '-c'? This would allow: #! /bin/shio sed -d $1 | tbl | nroff | lpr Of course, you then need cshrun, etc., which defeats the intent of #!. ++Brandon -- ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery <BACKBONE>!cbosgd!ncoast!allbery (NOW!!!!) aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery Mentor, OH 44060-4101 necntc!ncoast!allbery@harvard.HARVARD.EDU (Internet) +01 216 974 9210 ncoast!allbery@CWRU.EDU (CSnet -- if you dare) NCOAST ADMIN GROUP Brandon Allbery on 157/504 (Fidonet/Matrix/whatever) * ncoast -- Public Access UN*X -- (216) 781-6201, 24 hrs., 300/1200/2400 baud * * ncoast is proud to be carrying alt.all -- contact me for more information *
rbj@icst-cmr.arpa (Root Boy Jim) (07/16/87)
From: Jonathan Clark <jhc@mtune.ATT.COM> On a similar note, for the people who are expounding starting one's shell scripts with "#! /bin/csh", the logical continuation of this is to start one's C programs with "#! /bin/cc", and so on. Hey, why not? This is more inline with the philosophy of `object oriented programming'. There already exist tools floating around the net to pick out embedded execution lines in text. Think about it, what would it mean to `execute' a text file containing C code? Program, compile thyself! Writing a language processor which is a partial superset of an existing standard is one thing, and quite OK in my book; hacking the kernel to support this automagically is quite another. Perhaps csh should have been made to interpret a strict superset of the Bourne shell, so that normal scripts work under it, and then csh scripts should have been interpreted via "csh script"? Then we wouldn't have this problem. Yes we would. People like to write shells to do their own thing. I don't see this `hack' as a bad thing. It seems to be reasonably general, and I would guess doesn't take much code. The alternative is for the `exec' to fail, and the invoking program build a shell command and resubmit it. In addition, this lets a `script' choose its interpreter. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Th' MIND is the Pizza Palace of th' SOUL
bzs@bu-cs.bu.EDU (Barry Shein) (07/17/87)
> From: Jonathan Clark <jhc@mtune.ATT.COM> > > On a similar note, for the people who are expounding starting one's > shell scripts with "#! /bin/csh", the logical continuation of this is > to start one's C programs with "#! /bin/cc", and so on. > >Hey, why not? This is more inline with the philosophy of `object >oriented programming'... >(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> How come I am getting this sinking feeling we are re-inventing IBM's JCL... //JOBSTEP1 EXEC FORTG1 //SYSIN.GO DD * YOUR CARDS HERE :-) -Barry Shein, Boston University
ayac071@ut-ngp.UUCP (William T. Douglass) (07/18/87)
Keywords:Brain-damage, Regression >How come I am getting this sinking feeling we are re-inventing IBM's >JCL... > > //JOBSTEP1 EXEC FORTG1 > //SYSIN.GO DD * > YOUR CARDS HERE > >:-) > -Barry Shein, Boston University You left off a few, though. //SOMENAME JOB (XXXYYZZ),'Your Name',MSGLEVEL=(1,1),CLASS=D, // USER=XXYZZ,PASSWORD=, . . And, not to forget JES2 /*ROUTE PRINT RMT999 /*JOBPARM CARD.... and of course, how could we forget /* // Boy, those were the days. ;-) Bill Douglass
jay@splut.UUCP (Jay Maynard) (07/29/87)
In article <5642@ut-ngp.UUCP>, ayac071@ut-ngp.UUCP (William T. Douglass) writes: + >How come I am getting this sinking feeling we are re-inventing IBM's + >JCL... + > //JOBSTEP1 EXEC FORTG1 + > //SYSIN.GO DD * + > YOUR CARDS HERE + You left off a few, though. + //SOMENAME JOB (XXXYYZZ),'Your Name',MSGLEVEL=(1,1),CLASS=D, + // USER=XXYZZ,PASSWORD=, + /*ROUTE PRINT RMT999 + /*JOBPARM CARD.... + /* + // + + Boy, those were the days. ;-) Uh, Bill...I hate to break the news to you this way, but those still ARE the days. Not everyone is Unix, you know... Two more for you: //*MAIN ORG=RSOC1,CLASS=EXPEDITE //*FORMAT PR,DDNAME=SYSPRINT,COPIES=2,DEST=RMH06 (No, I don't like JES3, either...but that's what we're stuck with at my company.) -- >splut!<...Jay Maynard, K5ZC | uucp: ...!seismo!soma!uhnix1!sugar!splut!jay "Don't ask ME about Unix... | GEnie: JAYMAYNARD (...e-i-e-i-o!) I speak SNA!" | CI$: 71036,1603 FidoNet: SysOp @106/64 The opinions herein are shared by neither of my cats, much less anyone else.