Bug 65649

Summary: Add `-u name' option to env(1)
Product: Base System Reporter: Jos Backus <jos>
Component: binAssignee: Garance A Drosehn <gad>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.2-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Jos Backus 2004-04-17 06:00:41 UTC
	This patch adds the `-u name' option to env(1). For a rationale of why
	this is useful (besides compatibility with GNU coreutils), see this
	post:

	    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b083i6%2486c%241%40news5.svr.pol.co.uk
Comment 1 Garrett A. Wollman 2004-04-17 18:36:19 UTC
<<On 17 Apr 2004 04:54:52 -0000, Jos Backus <jos@catnook.com> said:

> 	This patch adds the `-u name' option to env(1). For a rationale of why
> 	this is useful (besides compatibility with GNU coreutils), see this
> 	post:

I can see the compatibility argument, but I think the utility is a bit
of a stretch.  Anything that `env -u FOO COMMAND' can do, you can do
with:

(unset FOO; COMMAND)

-GAWollman
Comment 2 Jos Backus 2004-04-17 20:08:17 UTC
On Sat, Apr 17, 2004 at 01:36:19PM -0400, Garrett Wollman wrote:
> <<On 17 Apr 2004 04:54:52 -0000, Jos Backus <jos@catnook.com> said:
> 
> > 	This patch adds the `-u name' option to env(1). For a rationale of why
> > 	this is useful (besides compatibility with GNU coreutils), see this
> > 	post:
> 
> I can see the compatibility argument, but I think the utility is a bit
> of a stretch.  Anything that `env -u FOO COMMAND' can do, you can do
> with:
> 
> (unset FOO; COMMAND)
 
But this also requires an extra shell invocation.

Moreover, the patch doesn't increase the executable nor bloat the code so it's
very unintrusive and gives us essentially free coreutils compatibility.

Jos

> -GAWollman

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'
Comment 3 Robin Breathe 2004-11-12 18:16:59 UTC
The original justification link is no longer working, however I believe 
the patch is justified. I found this PR in advance of implementing the 
functionality myself.

Setting the other valid arguments aside, it allows a shell-independent 
method for adjusting a utility's environment.

Consider the following:

sh:
# ( unset FOO; set BAR=BIM; COMMAND )
# ( unset FOO; env BAR=BIM COMMAND )

csh:
# ( unsetenv FOO; setenv BAR BIM; COMMAND )
# ( unsetenv FOO; env BAR=BIM COMMAND )

patch:
# env -u FOO BAR=BIM COMMAND

Regards,
Robin Breathe
Comment 4 Garance A Drosehn freebsd_committer freebsd_triage 2005-07-29 19:21:09 UTC
Responsible Changed
From-To: freebsd-bugs->gad

-  Given all that I have recently done to the `env' command, this seems 
like a reasonably useful option to also include.  For me, the primary 
use of `env' is to alter the environment before starting some program, 
*any* program, without requiring an extra invocation of /bin/sh just to 
get some tiny bit of work done.  This option for -u makes sense in that 
context (IMO).  I probably won't get to it in time for 6.0-release, but 
I will try to do it reasonably soon.
Comment 5 Garance A Drosehn freebsd_committer freebsd_triage 2005-07-29 22:58:53 UTC
I just wrote:

    For me, the primary use of `env' is to alter the environment
    before starting some program, *any* program, without requiring
    an extra invocation of /bin/sh just to get some tiny bit of
    work done.

I kept getting interrupted while writing (and re-writing) the
above, and somewhere along the line I dropped the key point I
wanted to make.  I meant: "using `env' to start some program
via the #!-line on the first line of a shell script".  It's in
*that* context, when used in the first line of a interpreted
script, where this option makes a lot of sense to me.

-- 
Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
Senior Systems Programmer               or   gad@FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
Comment 6 dfilter service freebsd_committer freebsd_triage 2008-04-18 00:17:25 UTC
gad         2008-04-17 23:17:09 UTC

  FreeBSD src repository

  Modified files:
    usr.bin/env          env.1 env.c 
  Log:
  Add the '-u name' option to the env command, which will completely unset
  the given variable name (removing it from the environment, instead of
  just setting it to a null value).
  
  PR:             bin/65649
  MFC after:      2 weeks
  
  Revision  Changes    Path
  1.10      +21 -5     src/usr.bin/env/env.1
  1.20      +10 -3     src/usr.bin/env/env.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 7 dfilter service freebsd_committer freebsd_triage 2008-05-13 22:47:01 UTC
gad         2008-05-13 21:46:50 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_7)
    usr.bin/env          env.1 env.c 
  Log:
  MFC *: Add the '-u name' option to the env command, which will completely
  unset the given variable name (removing it from the environment, instead
  of just setting it to a null value).
  
  [* = 1.10->1.11 env.1, 1.20 env.c]
  
  PR:             bin/65649
  
  Revision  Changes    Path
  1.9.10.1  +21 -5     src/usr.bin/env/env.1
  1.19.2.1  +10 -3     src/usr.bin/env/env.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 8 Garance A Drosehn freebsd_committer freebsd_triage 2008-05-13 23:47:33 UTC
State Changed
From-To: open->closed

I added the '-u name' option to 8.x-current on April 17th, 2008, 
and MFC-ed it to 7.0-stable on May 13th.  At this point I have no 
plans to MFC it to 6.x, but I could be talked into doing that.