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

[Jim Meyering]

Bauke Jan Douma wrote:

> Jim Meyering wrote on 10/26/2009 08:43 PM:
>> Pádraig Brady wrote:
>>
>>> Eric Blake wrote:
>>>> Since environment variables may contain newlines, but env and printenv
>>>> currently separate output entries via newline, we have a case of ambiguous
>>>> output.  For example, "env | sed -n '/^a.*=/ s,=.*,,p'" does not 
>>>> necessarily
>>>> tell you the set of environment variables beginning with "a", because I 
>>>> could
>>>> have done "export b=$'\na=c'".  What do list readers think of the idea of
>>>> adding:
>>>>
>>>> env -0/--null
>>>> printenv -0/--null
>>>>
>>>> as a means of unambiguously representing the current contents of the
>>>> environment with NUL terminators instead of newlines?
>>> It's consistent and makes sense.
>>> I've not needed it myself (I think :)),
>>> but I would say it's worth adding.
>>
>> I'm on the fence, partly because you can simulate printenv -0 with this:
>>
>>     perl -e 'print map {"$_=$ENV{$_}\0"} keys %ENV'
>>
>> You can simulate env -0 the same way.
>> Certainly, env -0 and printenv -0 are easier to type and use.
>> Not strongly for or against.
>
> ... ah, Jim, but this is /core/utils no?
>
> Wouldn't you agree therefore that historically as well
> as OS-constitutionally coreutils are more fundamental
> than perl? And, perhaps, therefore --at least in this
> case-- it has no business of referring to a youngster
> like perl?   ;-)

;-)
Besides, what's the point of a tool that cannot be made to work reliably?
Yes, now I'm in favor of this, too.