From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.questions
Subject: Re: Much Ado about Nothing: white space and sh and csh
Date: 8 Apr 1992 05:39:02 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: godot-1.think.com
Keywords: csh sh test expr

In article <1992Apr7.175911.20627@uxa.ecn.bgu.edu> mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff) writes:
>sh seems to not want spaces around  it's assignment operator.  It complains
>quite violently, when they are included.  I have the sh(1) manual in
>front of me.  There is no insignt provided as to the reason for this
>pickiness.

I assume whitespace isn't allowed here so that "=" can be used as part of a
normal command line argument.  The above looks like an invocation of the
"u" command with a first argument of "=".

The test command is an example of a program that uses = as an ordinary
argument.

>On a related note, recall that each operator in the expr command is a
>separate argument.    I found this documented in expr(1).

That was presumably done to simplify the tokenization step (i.e. let the
shell do it).  Also, since expr operates on both strings and numbers, it
permits you to use strings that look like expressions.  Thus,

	expr 3+3 = 4+2

returns false because it is doing a lexical comparison of the strings, but

	expr 3 + 3 = 4 + 2

returns true because it does an arithmetic comparison of the results of the
additions.

In a "real" programming language you would use quoting to disambiguate the
two.  But since the shell already uses quotes, it would be inconvenient to
have to put additional quotes in.

>On some other notes, in csh, the assignment operator is 
>of the form "@ space assignment statement"
>However, when I remove the space from after the "@", the csh is quite
>unhappy.

"@" is just a built-in command.  Like all other commands, it must be
delimited by a space.  It's not a shell metacharacter like ">" and ";".

>It really isn't too clear from csh(1) that @ would require this space.

Right here:

  Lexical Structure
     The shell splits input lines into words  at  SPACE  and  TAB
     characters,  except as noted below.

The "noted below" section doesn't mention "@".

>This makes csh violently ill.  It complains, 
>"while: Expression syntax."
>
>#
>@ i = 1
>
>while ( $i<=3 ) 
>  echo $i
>  @ i = $i + 1
>end
>
>The only difference is the spaces around the relational operator "<="
>Could csh be looking for the variable named "i<=3"?

I don't think so; the following elicits the same complaint:

while ( 3<=3 )
  echo foo
end

Apparently the C shell expression parser is similar to the expr command's
parser.

>Along the same lines, here the system is having trouble with the
>statement to increment i.  I suspect that it is looking for a variable
>called "i+1"

>  @ i = $i+1

>this time, the csh complains:
>
>@: Badly formed number

Since punctuation characters are variable name delimiters, I don't think
so.  I think it's complaining that 1+1 is a badly formed number.  As with
the previous example, csh's expression parser apparently requires tokens to
be delimited by spaces.

>However, we will see that various illogical carriage returns are required
>to make sh happy.

I think all your examples (which I've not repeated here) can be explained
by reference to the following quote from sh(1):

     The following words are only recognized as the first word of
     a command and when not quoted:

     if then else elif fi case esac for while until do done { }

This rule is necessary for cases like the "for" statement, so that tokens
such as "do" don't inadvertently terminate the list of words the iteration
variable will take, e.g.

for x in say do be a do bee dont be a dont bee
do
  echo $x
done

If "do" were recognized without prequiring a semicolon or newline, this
would be parsed as

for x in say
do
  be a do bee dont be a dont bee
  do
    echo $x
  done

>I haven't seen any other language as bizarre as this.

This is what happens when you try to make a language do double duty.
Shells are both simple command interpreters and programming languages, but
the requirements of the two are quite different.  This is why some people
got fed up and implemented alternate scripting languages such as perl.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar