Is this a bug in sh?

[Frank Wales]

[I tried mailing, but it bounced.]

In article <PAUL.89Jul4155856 at marvin.moncam.co.uk> paul at moncam.co.uk write:
>Consider the two (executable) shell scripts..
>
>script1 is		and  	script2 is
>
>echo $0				echo $0
>name=`basename $0`		name= `basename $0`
>				     ^
>			Note the space here.
>
>executing script1 prints "script1" as you would expect.  Executing
>script2 prints "script2" "script2" ...... and spawns shells at an
>enormous rate.

Valid shell construct number one;

Assignments to shell variables (a.k.a. keyword parameters) have the syntax:

	<varname>=<expression>

note...no spaces following the '='.  If <expression> is missing,
then <varname> is set to the null string.

Valid shell construct number two:

Execution of a command with a shell variable set to a particular
value *in the environment of that command only*:

	<varname>=<expression> <command string>

If <expression> is missing, <varname> is set to the null string while
<command string> is executed.  <command string> can be any shell expression
which results in a non-null string for subsequent execution.

Hence, in the example you give, the line:
	
	name= `basename $0`

sets name to the null string, evaluates the backquoted expression
(which results in the basename of the script), then executes the
script itself with name set to null.  This leads to unending
recursion of the script which contains it.

Today's complex technical question: based on this, decide what you
think the command line:

	binglebongle=Fred echo $binglebongle

will print, then try it and see what happens.  At this point, read the
manual.  :-)
--
Frank Wales, Systems Manager,        [frank at zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217