Re: [RFC] {print,}env -0

[Pádraig Brady]

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.