[comp.bugs.4bsd] csh oddity

chris@mimsy.UUCP (Chris Torek) (01/14/88)

>In article <826@murphy.UUCP> dcornutt@murphy.UUCP (Dave Cornutt) writes:
>>I have discovered something peculiar about csh variable substitution.  Is
>>this a bug or am I doing something wrong?

[the bug reduces to

	set x1=test
	echo ${x1}
]

In article <1269@mips.UUCP>, hansen@mips.UUCP (Craig Hansen) writes:
>You're doing something wrong. The correct syntax is:
>% set xy1z={$xy1z}_123

Naah.

*** sh.lex.c.old	Wed Jan 13 20:22:06 1988
--- sh.lex.c	Wed Jan 13 20:22:10 1988
***************
*** 373,377 ****
  			}
  		} else if (letter(c))
! 			while (letter(c = getC(DOEXCL))) {
  				if (np < &name[sizeof name / 2])
  					*np++ = c;
--- 373,377 ----
  			}
  		} else if (letter(c))
! 			while (letter(c = getC(DOEXCL)) || digit(c)) {
  				if (np < &name[sizeof name / 2])
  					*np++ = c;

The amusing part is that the code in sh.dol.c was all set to handle
text of the form `{ALPHA}{ALNUM}*', but sh.lex.c never let it get
that far.  This `Variable syntax' error is coming from the `lexical
analyser', not the variable evaluator.  That one has one of its
own, used if the `lexer' lets something wrong go through.  Sheer
idiocy: two routines to do the same job.

Craig's workaround is fine if the expansion of $xy1z does not
contain a comma.

	% set a=a,b,c
	% echo ${a}
	a,b,c
	% set a1=a,b,c
	% echo {$a1}
	a b c

Here the {}s indicate set notation, rather than variable name
restriction.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris