Eric Blake wrote:
>
> I went ahead and added one more patch to my queue (shown below), then pushed.
nice examples, thanks.
> Meanwhile, I just noticed the following unusual behavior:
>
> $ env a=b=c printenv a=b
> c
> $ env a=b=c tcsh -c 'printenv a=b'
> c
>
> Part of me thinks this is a bug (a=b is an invalid environment name, so
> this should either print nothing, or fail with an error message),
> particularly since I just changed env -u a=b to give an error for the same
> case; but another part of me says that since tcsh has the same behavior,
> we might be gratuitously breaking things by changing how printenv.c deals
> with this corner case. Right now, I'm leaning 75-25 on changing
> coreutils' behavior (treating a=b as an env-var name just seems wrong, and
> tcsh is so painful to use in general that I could care less if we don't
> match the behavior of the tcsh builtin); and if we do change behavior, I'm
> leaning 60-40 on making printenv a=b be silent (with exit status 1, since
> no value was printed) rather than issue an error (with exit status 2,
> because the user passed bad arguments). Other opinions?
$ a=b=c printenv a
b=c
$ a=b=c printenv a=b
c
That looks like a bug to me.
Hmm what to do. Since `printenv` is just for displaying variables
I would just display nothing and exit 1 as you say. The same
way other "invalid" identifiers are handled like: printenv -
cheers,
Pádraig.
As a side note in all shells `echo ${a=default}` (even without :=)
is used to return a default if $a is unassigned.
