From owner-cvs-src@FreeBSD.ORG Tue Jun 21 11:37:49 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CED716A41C; Tue, 21 Jun 2005 11:37:49 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 484C943D48; Tue, 21 Jun 2005 11:37:49 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.84.87) by smtp01.syd.iprimus.net.au (7.2.060.1) id 42A0AD7E00591739; Tue, 21 Jun 2005 21:37:48 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 2550D438B; Tue, 21 Jun 2005 21:37:48 +1000 (EST) Date: Tue, 21 Jun 2005 21:37:48 +1000 From: Tim Robbins To: Garance A Drosehn Message-ID: <20050621113748.GA59399@cat.robbins.dropbear.id.au> References: <200506200314.j5K3EUtt089472@repoman.freebsd.org> <20050620094103.GB54301@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/env env.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2005 11:37:49 -0000 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