kevin@kosman.UUCP (Kevin O'Gorman) (05/30/87)
I am running Ultrix 1.2A (a Berkely type thing) and have written two shell
programs:
/etc/daily
/etc/monthly
for backup purposes. The odd thing is that they are almost identical, the
exceptions being one argument to dump(8) and some commentary. They have the
same owner, group, and permissions. What's odd is that there's a read
command which works in one (daily) and fails in the other (monthly), with
a message something like
read: not found
which makes me think that daily runs under /bin/sh (which has 'read' builtin),
and that monthly runs under /bin/csh (which gives the exact same error message).
Problem is, I cannot figure out any reason for the difference. Is there some
secret I'm bumping into, and just haven't seen the documentation on it yet?
HELP - confusion makes me grumpy
--
Kevin O'Gorman
...{decvax,allegra}!philabs!hhb!kosman!kevinamos@instable.UUCP (06/02/87)
In article <243@kosman.UUCP> kevin@kosman.UUCP (Kevin O'Gorman) writes: (Trouble with 2 command files, one runs under /bin/sh and the other runs under /bin/csh). >The odd thing is that they are almost identical, the >exceptions being one argument to dump(8) and some commentary. ^^^^^^^^^^^^^^^ On most Unix systems and clones, if an executable file does not start with the proper magic word, /bin/sh is started to execute it. On old BSD-derived systems, if the file starts with a '#', csh is used instead; this was later expanded to define '#!' as a new magic word, indicating an interpreter to feed the file into for execution. Your file probably starts with a '#' comment; just adding a blank line before it should solve the problem. -- Amos Shapir National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261 amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N
avolio@decuac.UUCP (06/02/87)
In article <243@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > I am running Ultrix 1.2A (a Berkely type thing) and have written two shell > programs: > /etc/daily > /etc/monthly > for backup purposes. The odd thing is that they are almost identical, the > exceptions being one argument to dump(8) and some commentary. ... !!!!!!!!!! One starts right in with the shell commands and the other starts with a comment beginning with a '#', right? Any shell script that the C Shell sees that begins with a comment it assumes should run with the /bin/csh, else it runs /bin/sh on it. Begin both scripts (assuming that they are written for Bourne Shell) with the line: #! /bin/sh Just a side note... based on your other postings recently I think that you might benefit from a DECstart Ultrix service at your site. This is not a put-down, please believe me. It just might be worth it to have someone come down and go through all of this with you for a day. Call your DEC sales rep or drop me a note if you do not know him|her. Fred
ray3rd@ssc-vax.UUCP (Ray E Saddler III) (06/02/87)
In article <243@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > I am running Ultrix 1.2A (a Berkely type thing) and have written two shell > programs: > > .....(other information about his shell scripts)..... > > -- > Kevin O'Gorman > ...{decvax,allegra}!philabs!hhb!kosman!kevin Some time ago I wrote some shell scripts to run in /bin/sh, and for some reason, they ran in /bin/csh. The fix is to insert a line at the beginning of the script: #!/bin/sh This, for some [magic] reason, forces the script file to run under the Bourne shell. Maybe some guru/wizard/hacker out ther can elaborate on why this happens. All I know (and care about) is that it works! ;) Also, another thing that works is to insert 1 space before your first word in the script: echo "Super Script: POWERBACK" echo " " echo "Another marvelous script written by ME" .. .. .. all the things that the script does .. .. exit 0 Give them a try! If they don't work, well, it's due to some unique feature/bug about Ultrix that I'm not familiar with! -- Ray E. Saddler III CAD Support and Administration | __ __ __ __ Boeing Aerospace Company Ballistic Systems Division | / / / // //| // P.O. Box 3999 M.S. 3R-05 Kent Space Center East | /-< / //- // |// _ Seattle, Wa. 98124 USA (206)657-2824 or (206)657-3369 | /__//_//__ // //__/
gwyn@brl-smoke.UUCP (06/04/87)
In article <1270@ssc-vax.UUCP> ray3rd@ssc-vax.UUCP (Ray E Saddler III) writes: >#!/bin/sh I guess it's about time to repeat the explanation: UNIX shells attempt run a command via the exec() system call, and if it fails because the command file does not have valid format for an executable binary, then they assume it must be a shell script. Many implementations of csh stupidly then peek at the first character of the script and if it's "#" they assume it must be a csh script rather than an sh script. (That's a BUG. All my sh scripts but one start with "#".) What #! etc. does is that on SOME kernels (such as 4.nBSD) the kernel thereby recognizes that the command file is input for an interpreter and "succeeds" in the exec() system call by running the interpreter for you. This is convenient but kludgy (sorry, Dennis). Therefore the invoking shell never enters the code that would take over when an exec() fails.
rbj@icst-cmr.arpa (06/05/87)
Many implementations of csh stupidly then peek at the first character of the script and if it's "#" they assume it must be a csh script rather than an sh script. (That's a BUG. All my sh scripts but one start with "#".) I suspect you will get a lot of disagreement to that. I'm such you are aware of what I am about to say, but I'll state it anyway for those who don't and to make my reasoning clear. When csh was written, there was only one other shell around. It might have been presumptuous to proclaim itself *the* shell. So some method had to be found to distinguish one flavor of shell script from another. It would have been laughable to expect people to change all their existing scripts just so some grad student from a western university could distinguish input meant for his program rather than one written by several PhD's at an eastern public utility research lab. So he did the next best thing, and proclaimed that his program wouldn't run anything unless the first character was an octothorp, and would defer to his better educated predecessors' program instead. At that time, that venerable program he was trying to replace didn't know about hashes, it used colon's for comments. I suggest you do as well. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
gwyn@BRL.ARPA (VLD/VMB) (06/05/87)
: is NOT a comment in the Bourne shell -- it's a command. # is the comment character (at least it has been for several years). : is not a suitable replacement for # for reasons that should be obvious.
dhesi@zoo-hq.UUCP (06/05/87)
In article <5943@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) (discussing how the exec() system call works on non- a.out executable files) writes: > ....Many implementations of csh stupidly then >peek at the first character of the script and if it's "#" >they assume it must be a csh script rather than an sh script. >(That's a BUG. All my sh scripts but one start with "#".) I don't know if it's csh that peeks at that #, or if it's the library routine that does it before deciding whether to call the kernel's exec() routine, or the kernel exec() routine itself, or all of them. In any case, it's a FEATURE and not a bug. It is a generalized feature that will allow multiple shells and their scripts to coexist. 4.3BSD works very nicely with however many shells you have -- just make sure each shell script begins with "#! /bin/sh" or "#! /bin/csh -f" etc. System V chokes when it sees a csh script, because there is no uniform mechanism to handle multiple shells (this based on what I see on my UNIX PC and my Microport SVR2 systems). (It's supposed to work if you put a ": use /bin/csh" line at the beginning of a script. It doesn't.) In defense of the default csh interpreter obtained when # is not followed by an exclamation mark: Wasn't there a time when the Bourne shell did NOT accept # as a comment character? If so, and if csh was the first shell to use # for comments, it makes perfect sense that # implies a csh script. -- Rahul Dhesi UUCP: {seismo,ihnp4}!{pur-ee,iuvax}!bsu-cs!dhesi
chris@mimsy.UUCP (06/05/87)
Ah, the wonders of modern science! With infinite ease (well, some organisation on my part might make it infinite), MH retrieves a saved article, and ... wallah! [*] [*If you think this `voila' misspelled, try again] (Message save:98) From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix-wizards Subject: Re: # sign in shell/cshell scripts... Date: 17 Apr 86 20:30:30 GMT Once upon a time, there was the shell. Since there was only `the' shell, there was no trouble deciding how to run a script: run it with *the* shell. It worked, and everyone was happy. Along came progress, and wrote another shell. The people thought this was good, for now they could choose their own shells. So some chose the one, and some the other, and they wrote shell scripts and were happy. But one day someone who used the `other' shell ran a script by someone who use the `other other' shell, and alas! it bombed spectacularly. The people wailed and called upon their Guru for help. `Well,' said the Guru, `I see the problem. The one shell and the other are not compatible. We must ensure that the shells know which other shell to use to run each script. And lo! the one shell has a ``comment'' called ``:'', and the other a true comment called ``#''. I hereby decree that henceforth, the one shell will run scripts that start with ``:'', and the other those that start with ``#''.' And it was so, and the people were happy. But progress was not finished. This time he noticed that only shells ran scripts, and thought that if the kernel too could run scripts, that this would be good, and the people would be happy. So he wrote more code, and now the kernel could run scripts, but only if they began with the magic incantation: `#!', and told the kernel which shell ran the script. And it was so, and the people were confused. For the `#!' looked like a `comment'. Though the kernel could see the `#!' and run a shell, it would not do so unless certain magic bits were set. And if the incantation were mispronounced, that too could stop the kernel, which after all was not omniscient. And so the people wailed, but alas!, the Guru did not respond. And so it was, and still it is today. * * * * * Anyway, you will get best results from a 4BSD machine by using #! /bin/sh or #! /bin/csh as the first line of your script. `#! /bin/csh -f' is also helpful on occasion. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
paul@tut.cis.ohio-state.edu.cis.ohio-state.edu (Paul Placeway) (06/05/87)
In article <7710@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: ... >It would have been laughable to expect people to change all their >existing scripts just so some grad student from a western university >could distinguish input meant for his program rather than one written >by several PhD's at an eastern public utility research lab. So he did >the next best thing, and proclaimed that his program wouldn't run >anything unless the first character was an octothorp, and would defer >to his better educated predecessors' program instead. ... > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> It seems to be that Jim is being fast and loose with the better education implies better programming paridigm here. Bourn shell works, and has fewer bugs than Csh does, but if you look at the sources, you will discover that the thing is written in a poor excuse for Algol, implemented with the C pre-processor. Also, memory is allocated by trying to access the new memory, then if a segmentation fault happens, allocate by moving the break forward and trying again. Pretty poor programming practice. Csh, on the other hand, will try to free random parts of memory, and expects the allocator to deal with it (actually, it bounds checks the things, but still...). Also poor. Csh, however, did inovate a number of usefull things such as aliases (now in Korn Shell) and job control (well, csh _uses_ job control, the BSD kernal implements it...) It just goes to show: anyone, PhD or not, can implement good ideas with bad code... 8-) -=- -- Paul Placeway Department of Computer and Information Science SNail: The Ohio State University 2036 Neil Ave. Columbus OH USA 43210-1277 ARPA: paul@ohio-state.{arpa,csnet} (soon): paul@tut.cis.ohio-state.edu UUCP: ...!cbosgd!osu-eddie!paul
mouse@mcgill-vision.UUCP (06/07/87)
In article <243@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > I am running Ultrix 1.2A (a Berkely type thing) and have written two > shell programs [which] are almost identical, the exceptions being one > argument to dump(8) and some commentary. [...] a read command [] > works in one (daily) and fails in the other (monthly), with a message > something like > read: not found > which makes me think that daily runs under /bin/sh (which has 'read' > builtin), and that monthly runs under /bin/csh (which gives the exact > same error message). "some commentary" - are you aware of the #! convention? If a shell script's first two bytes (ie, the first two bytes of the first line) are #! then the rest of the line is taken to indicate what shell is to be used to run the script. For example, if one says #! /bin/sh and the other says #! /bin/csh then that explains it. Failing that, check out how they are run. Is one run via "sh .../daily" and the other via "csh .../monthly" or something? der Mouse (mouse@mcgill-vision.uucp)
ken@braegen.UUCP (Ken Marchant) (06/10/87)
> : is NOT a comment in the Bourne shell -- it's a command. > # is the comment character (at least it has been for several > years). : is not a suitable replacement for # for reasons > that should be obvious. : is the only decent substitute for a comment in the early bourne shells that I have used (version 7, Xenix 2.1 SYS III?). The reasons ain't so obvious to people who haven't used this. (ie. shell substitutions failing in the comment when there is no match for filenames etc.) A simple, mostly safe policy is to begin bourne shells with something like a blank line or a line with a single :. and begin c-shells with a #. As long as you know something about shell programs this never presents an irremediable problem. -- Ken Marchant The Braegen Group, Toronto, Ontario (allegra,linus,ihnp4,decvax)!utzoo!yetti!geac!braegen!ken
rbj@icst-cmr.arpa (Root Boy Jim) (06/10/87)
? : is NOT a comment in the Bourne shell -- it's a command. ? # is the comment character (at least it has been for several ? years). : is not a suitable replacement for # for reasons ? that should be obvious. True enuf. It does restrict your character set. I take your silence on the rest of my posting to mean that my account was reasonably factual. My quibble with TPC is that after so much care by Bill Joy to accommodate the original shell, they didn't return the consideration. They ignored the well established convention that csh uses by using the same comment character. They seem to think no one else exists but them. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 PARDON me, am I speaking ENGLISH?
rbj@icst-cmr.arpa (Root Boy Jim) (06/10/87)
>It would have been laughable to expect people to change all their >existing scripts just so some grad student from a western university >could distinguish input meant for his program rather than one written >by several PhD's at an eastern public utility research lab. So he did >the next best thing, and proclaimed that his program wouldn't run >anything unless the first character was an octothorp, and would defer >to his better educated predecessors' program instead. ... > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> It seems to be that Jim is being fast and loose with the better education implies better programming paridigm here. Bourn shell works, I don't think there's any doubt which camp I stand in. I was being cute. and has fewer bugs than Csh does, but if you look at the sources, you will discover that the thing is written in a poor excuse for Algol, implemented with the C pre-processor. Also, memory is allocated by So what? I commend the guy for doing things his own way instead of merely going along with someone's poor excuse for syntax, namely the `one statement if model'. Since this is not net.lang.c I won't belabor the point. Whether you like or dislike this style is up to you, but if anyone who has trouble with it should be ashamed. trying to access the new memory, then if a segmentation fault happens, allocate by moving the break forward and trying again. Pretty poor programming practice. I don't see why. By that argument, demand paging sucks too. And how do you think user programs get new stack space allocated? -- Paul Placeway Department of Computer and Information Science SNail: The Ohio State University 2036 Neil Ave. Columbus OH USA 43210-1277 ARPA: paul@ohio-state.{arpa,csnet} (soon): paul@tut.cis.ohio-state.edu UUCP: ...!cbosgd!osu-eddie!paul (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Maybe we could paint GOLDIE HAWN a rich PRUSSIAN BLUE--
robertd@ncoast.UUCP (Rob DeMarco) (06/10/87)
(You will problibly get a lot of mail on this subject so I will try to be brief) You say that the one shell script with comments in it wount except the read command. Here's your problem. When typing in a file that is a shell script the system defaults to running /bin/sh on it. (At least on ncoast it does) Well, if you are running csh and type in a command that is a shell script then the system will run /bin/sh. BUT if the first, and I mean FIRST line of your file is a comment , (beginning with "#") then it will run /bin/csh on it!!!! So, stick a blank line as the first line of your file and you should be ok. [> Rd -- [=====================================] [ Rob DeMarco ] [ UUCP:decvax!cwruecmp!ncoast!robertd ] [ ] [ "I hate 'Wheel of fortune'....and ] [ proud of it!!" ] [=====================================]
allbery@ncoast.UUCP (Brandon Allbery) (06/11/87)
As quoted from <5@zoo-hq.UUCP> by dhesi@zoo-hq.UUCP (Rahul Dhesi): +--------------- | 4.3BSD works very nicely with however many shells you have -- just make | sure each shell script begins with "#! /bin/sh" or "#! /bin/csh -f" etc. | System V chokes when it sees a csh script, because there is no uniform | mechanism to handle multiple shells (this based on what I see on my UNIX | PC and my Microport SVR2 systems). (It's supposed to work if you put a | ": use /bin/csh" line at the beginning of a script. It doesn't.) +--------------- That's because the intended interpreter of that line ignored it. Guess what? The intended interpreter is the person who runs it. (System V doesn't HAVE csh -- it has ksh. (Unless the VAR who sold it to you added it.) Ksh is sh compatible, so who cares?) Perhaps I should repost "bexec" again. (For those interested: it uses the "alias shell" feature in some (all?) csh's to implement execution of many unusual kinds of files. It (1) interprets #! lines (but does NOT implement setuid); (2) checks for binary files and invokes runcobol (RM/COBOL interpreter) on those; and (3) if all else fails, runs /bin/sh. I swear by it.) -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. ---- Moderator for comp.sources.misc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
terryl@tekcrl.TEK.COM (06/11/87)
I was going to stay out of this, but since everyone else is going to
put their $0.02 in, so will I.....
In article <7804@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes:
+
+ >It would have been laughable to expect people to change all their
+ >existing scripts just so some grad student from a western university
+ >could distinguish input meant for his program rather than one written
+ >by several PhD's at an eastern public utility research lab. So he did
+ >the next best thing, and proclaimed that his program wouldn't run
+ >anything unless the first character was an octothorp, and would defer
+ >to his better educated predecessors' program instead.
+ ...
+ > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
+
+ It seems to be that Jim is being fast and loose with the better
+ education implies better programming paridigm here. Bourn shell works,
+
+I don't think there's any doubt which camp I stand in. I was being cute.
+
+ and has fewer bugs than Csh does, but if you look at the sources, you
+ will discover that the thing is written in a poor excuse for Algol,
+ implemented with the C pre-processor. Also, memory is allocated by
This is a real joke (no (-: here). Try running lint on the Bourne shell
source. When we were porting things to a 68000-based system, the Bourne shell
caused us MUCH more grief than both csh and vi put together. (The only real
bug I can remember from either csh or vi, but can't remember which, was trying
to read 1 character into a short variable; definitely not kosher on a big-
endian machine such as the 68000).
+So what? I commend the guy for doing things his own way instead of
+merely going along with someone's poor excuse for syntax, namely the
+`one statement if model'. Since this is not net.lang.c I won't
+belabor the point. Whether you like or dislike this style is up to
+you, but if anyone who has trouble with it should be ashamed.
+
+ trying to access the new memory, then if a segmentation fault happens,
+ allocate by moving the break forward and trying again. Pretty poor
+ programming practice.
+
+I don't see why. By that argument, demand paging sucks too. And how
+do you think user programs get new stack space allocated?
Let's compare apples to apples, not apples to oranges. Trying to access
memory outside of your current allocation is a bug, pure and simple (and one
that was fairly well documented in V7; I don't have any experience with earlier
versions). You wouldn't believe the kludges we had to put into the compiler
and the kernel to support the Bourne style of memory management. Ditto that
comment about "pretty poor programming practice". Luckily, we were able to get
rid of those kludges when the 68010 came out. Demand paging is only valid for
those systems whose hardware supports it; a 68000 by itself could not support
demand pagaing (I'm not counting those systems that used a second 68000 to
bring in the faulted page while the main processor was essentially halted
until that page was brought in).
As for the comment about how user programs get new space allocated, it is
a valid one, though. That one was solved by our hardware memory management
unit.
My main complaint with the Bourne shell was that is relies on some pretty
heavy assumptions about the processor (either implicitly or explicitly). The
biggie is that if an instruction generates a memory reference that is currently
outside the range of allowable addresses (i.e. what is termed a "bus fault or
bus error" in Unix jargon), then that instruction can be magically restarted
AFTER some user level code has executed. Yuck!!!!!
Terry Laskodi
of
Tektronixgwyn@brl-smoke.UUCP (06/14/87)
In article <7803@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >I take your silence on the rest of my posting to mean that my account >was reasonably factual. You're taking more than I'm giving, then. All my silence means is that I don't feel I had anything to say worth posting. Your idea that AT&T (which you keep calling TPC for no good reason) was engaged in a conspiracy against the Cshell when it first picked # for a shell comment character is unfounded. I suspect if they had chosen some other comment convention you would have railed against them for not using the same convention as the Cshell.
rbj@icst-cmr.arpa (06/17/87)
In article <7803@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >I take your silence on the rest of my posting to mean that my account >was reasonably factual. You're taking more than I'm giving, then. All my silence means is that I don't feel I had anything to say worth posting. You are very aggressive at correcting errors. I claim that my account of the facts (if maybe not the tone) is close enuf to the truth, or you would have mentioned something about it. Your idea that AT&T (which you keep calling TPC for no good reason) was engaged in a conspiracy against the Cshell when it first picked # for a shell comment character is unfounded. I didn't say conspiracy. I said that AT&TPC (how's that for compromise) didn't afford csh the same care that Bill Joy showed sh. I suspect if they had chosen some other comment convention you would have railed against them for not using the same convention as the Cshell. Good point, but you are still avoiding the issue. I took you to task for railing against csh (and BSD sh) for deciding whether to run a shell script under either csh or sh. Obviously, *some* attempt must be made to determine which shell to use. And that complicates matters. One must conform or get bitten. The environment variable SHELL comes to mind, but is quickly discarded. The information must be *in the script itself*. The #! convention is (a start at) a good general solution, as there are bound to be more than two shells, just as there are bound to be more than one. How would you distinguish which shell to run? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
kak@stc-auts.UUCP (06/17/87)
I will just barely refrain from saying what I think about a command language which uses comments as control structures.
chris@mimsy.UUCP (Chris Torek) (06/18/87)
In article <206@stc-auts.UUCP> kak@stc-auts.UUCP (Kris Kugel) writes: >Summary: software engineering and csh #! >I will just barely refrain from saying what I think about >a command language which uses comments as control structures. ? `#!' is interpreted by the *kernel*, not the C shell. The C shell ignores the comment. (Peeking at the first character of the script is done after exec() fails; #! ensures that exec() does not fail.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
tytso@athena.mit.edu (Theodore Y. Ts'o) (06/18/87)
In article <206@stc-auts.UUCP> kak@stc-auts.UUCP (Kris Kugel) writes: > >I will just barely refrain from saying what I think about >a command language which uses comments as control structures. Lots of languages do it: Pascal.... {$U+} C..... /* VARARGS */ Granted, they're not *control* structures, but neither is #!/bin/csh -f Think of it as more of a run time option..... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Theodore Ts'o | mit-eddie!mit-athena!tytso | M.I.T., tytso@athena.mit.edu | P.h.D., 3 Ames St., Cambridge, MA 02139 | M.O.N.E.Y.! | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
guy%gorodish@Sun.COM (Guy Harris) (06/19/87)
> I will just barely refrain from saying what I think about > a command language which uses comments as control structures. Thank you for doing so; I know of no shell on UNIX that does this. "#!" is not a control structure. It is a cookie that is recognized by the kernel on some systems when it appears at the front of a file to be executed, just like the various other magic numbers. The only reason why it begins with a character that is commonly used as a comment character is that any other choice would run a greater risk of confusing the interpreter program when it reads the file, or would require more potential interpreter characters to be changed. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
allbery@ncoast.UUCP (06/21/87)
As quoted from <206@stc-auts.UUCP> by kak@stc-auts.UUCP (Kris Kugel): +--------------- | I will just barely refrain from saying what I think about | a command language which uses comments as control structures. +--------------- Which presumably includes '#n' comments in System V sed? (Now THAT'S a useless change. Under BSD I can see it, as you can't do a "#! sed -n -f". But System V doesn't have #!, so why can't you just say sed -n -f???) ++Brandon -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. (Stargate take heed!) ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
rbj@icst-cmr.arpa (Root Boy Jim) (06/22/87)
In article <206@stc-auts.UUCP> kak@stc-auts.UUCP (Kris Kugel) writes: >Summary: software engineering and csh #! >I will just barely refrain from saying what I think about >a command language which uses comments as control structures. You're not gonna like TECO then. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 My Aunt MAUREEN was a military advisor to IKE & TINA TURNER!!
roy@phri.UUCP (Roy Smith) (06/23/87)
In article <206@stc-auts.UUCP> kak@stc-auts.UUCP (Kris Kugel) writes: > I will just barely refrain from saying what I think about > a command language which uses comments as control structures. An interesting statement. In general, I have to agree with Kris. I find, for example, the commented lintisms in C (i.e. "/* NOTREACHED */") kind of ugly, but given the need for backward compatability, I'm not sure there was any other way. The lintisms and the #! shell convention have something in common; both were an attempt to add features to an existing system while maintaining compatability with previous implementations. On the other hand, take a look at something like PostScript. PS had structured comments built into the language definition from the beginning (or at least from the time I first heard about it, a few years ago). This sort of assumes that there will be 2 fundamentally different interpreters looking at your PS program. A PS printer will ignore the comments and execute the program. The spooling and page-manipulation software ignores the code and only looks at the comments. Perhaps the right way to look at it is that you have 2 distinct programs, written in two distinct languages, intermingled in the same source file. One language considers any line starting with a "%" to be a comment, the other takes the complementary view and considers comments to be any line NOT starting with a "%". -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016