cvs commit: src/usr.bin/env env.c

[Tim Robbins]

On Mon, Jun 20, 2005 at 01:47:59PM -0400, Garance A Drosehn wrote:
> At 7:41 PM +1000 6/20/05, Tim Robbins wrote:
> >On Mon, Jun 20, 2005, Garance A Drosehn wrote:
> > > gad         2005-06-20 03:14:29 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     usr.bin/env          env.c
> >>   Log:
> > >   If the `utility' specified starts with a '/' character, then
> > >   execute it without checking it for an equals-sign.  If it
> > >   starts with a slash, then it cannot be a request to set the
> > >   value of a valid environment variable.
> >
> >This is not strictly correct:
> >
> >	The value of an environment variable is a string of characters.
>         ...
> >	These strings have the form name=value; names shall not contain
> >	the character '='. For values to be portable across systems
> >	conforming to IEEE Std 1003.1-2001, the value shall be composed
> >	of characters from the portable character set (except NUL and as
> >	indicated below).
> 
> Ah.  I jumped to the wrong conclusion based on the description of
> setting environment variables in the man page for 'sh'.  Neither
> sh nor bash allow you to set /SOMEVAR=YES.  setenv in csh seems to
> let you set a value, but then it complains 'Illegal variable name'
> if you try to reference it...
> 
> >Also, please be careful when adding new non-standard options and
> >features; they tend to stick around forever.
> 
> These *are* intended to stick around forever.  In fact, they are
> designed in such a way that other OS's could pick up the changes.
> 
> For the benefit of anyone reading this and considering similar
> changes, note that I did ask on -arch before adding these features
> (well, except for the '/' check).  No one complained.  re@ was asked
> before these commits were made.  I tested this on three platforms
> before making the commit and I compiled it on two more.  I *am*
> careful, and am somewhat annoyed that you feel you had to tell me
> to be careful after I had spent so much time looking for feedback
> before making most of these changes...  How much "more careful"
> does a guy have to get?  No, wait, don't answer that!!  This is
> about as careful as I intend to get!   :-)

I apologise if you took personal offense to this comment. Admittedly
it was a little terse. I get the feeling that people often don't
think things through before adding new options to the core utilities
(e.g. cat), but this is a general observation and not directed
specifically at the new env options. So, to make things absolutely
clear: I don't object to the new options, and I didn't mean for my
comments to offend.

> But I wouldn't mind to undo the '/' check, if people think that's
> a problem.  I only came up with that idea just before I was ready
> to commit, while I was stealing lines from the 'sh' man page...

I think this would be best. It's an obscure edge case, but I'd prefer
that we leant towards POSIX (which permits "/" in a portable
environment variable name but not "=" in a portable file name) rather
than leaning away from it for little gain.


Tim