history question-- Bourne (and C) SHELL COMMENTS

[David Korn]

> > OK, we're from a mixed (SysV, 4bsd, V6, V7) background here, and a
> > question has come up which NO ONE is clear on:
> > 	How do you put a comment in a shell script?
> 
> If you've got a mixture of new, old, and ancient shells, you're out
> of luck:  there is no single entirely satisfactory way.
> 
> > Some say that the colon introduces a comment, but that is not entirely true,
> > since the line still gets evaluated, at least somewhat.  So what is the
> > purpose of the colon?  It's not a comment, but it is????
> 
> The shell's command parser and preparation phases don't know that colon is
> anything special, so they treat it as an ordinary command.  The execution
> phase knows that colon is a special command which does nothing.  So you
> can put anything you want in colon's arguments, and it will be ignored,
> *if* it has no special significance to the earlier phases.  This is
> not entirely satisfactory because it means that things like ">" cannot
> appear unless they are backslashed or quoted, and things like "'" get
> very tricky.
> 
> > Others say that it is the sharp/pound/number sign, "#" <--that thing, but
> > if you're on a bsd system, you can't START your Bourne shell script with
> > it, or the C shell will run your script.
> 
> In modern shells, # at the beginning of a "word" means that the rest of
> the line is a comment.  This is the new standard convention.  Unfortunately,
> some old shells don't cope properly.  In particular, old broken C shells
> think a # at the beginning means "C shell script".  The fix to this is
> to get a modern C shell.
> 
> > Or should you start with
> >	#!/bin/sh
> > ???  And does the csh fork here, or exec?
> 
> In recent Unix versions, "#!" at the very start of a file is handled
> specially by the kernel, and the C shell never gets involved if the
> command specified is "/bin/sh".  "#!/bin/sh" tells the kernel itself to
> fire up a copy of /bin/sh and run the rest of the file into it.  It's a
> general way to specify the interpreter for a command file.
> 
> > What is the historical development of the : and the # ?  I am SURE that
> > the colon was the character to use in V7, but....
> 
> The # arrived in the Bourne shell shortly after V7; I'm not sure of its
> history in the C shell.  : was the old way to do things, with # introduced
> partly because : was so unsatisfactory.  As an added bonus, by the way,
> # is a good deal more efficient, since the shell isn't wasting a lot of
> preparation on the do-nothing : command.
> 
> > There are several methods to use here.  Which is the one of choice? and why?
> 
> If you must cope with old systems, either ones that don't recognize # or
> ones with C shells that misinterpret it, you must use : for comments.
> Otherwise, you should use # because it's less hassle and more efficient.
> You should probably use #!/bin/sh at the start of shell files, since it's
> harmless in systems whose kernels don't know about "#!" and useful in
> those that do.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

If you must write shell programs to work on old versions of the shell and
new ones you might use
: # comments go here
Since this will always work and on newer versions of the shell that allow
# for comment the arguments to the : command will not be expanded.
It is best to put the comment in single quotes to avoid any argument processing
in case the  shell doesn't recognize the # as a comment character.

The #! /bin/sh on the first line is interpretted by the kernel in BSD 4.2.
This has two unfortunate consequences.  First of all it execs a new copy
of the shell to run the shell procedure even if you are already running
the Bourne shell.  This is a lot slower than just letting the exec
fail and letting the shell read the procedure directly.

Secondly, this allows for a very insecure implementation of setuid shell
procedures.  Given any setuid shell procedure written using this mechanism
anyone can get the power to do anything that the owner of this procedure
can do.  (The mechanism for setuid and execute only shell procedures that
I use for ksh doesn't rely on kernel changes and doesn't have these
obvious security problems).

David Korn
ulysses!dgk