From j@uriah.heep.sax.de  Mon Mar 10 16:22:22 1997
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA10852
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 10 Mar 1997 16:22:10 -0800 (PST)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA16402 for FreeBSD-gnats-submit@freebsd.org; Tue, 11 Mar 1997 01:21:26 +0100
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.5/8.8.5) id AAA10899;
	Tue, 11 Mar 1997 00:55:56 +0100 (MET)
Message-Id: <199703102355.AAA10899@uriah.heep.sax.de>
Date: Tue, 11 Mar 1997 00:55:56 +0100 (MET)
From: " steve  howe" <un_x@hotmail.com>
Reply-To: un_x@hotmail.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: sh(1) has problems with $ENV
X-Send-Pr-Version: 3.2

>Number:         2934
>Category:       bin
>Synopsis:       sh(1) has problems with $ENV
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gabor
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 10 16:30:02 PST 1997
>Closed-Date:    Mon Dec 25 21:36:03 GMT 2006
>Last-Modified:  Mon Dec 25 21:36:03 GMT 2006
>Originator:     steve howe
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
unknown
>Environment:

/bin/sh in any FreeBSD system so far.

>Description:

/bin/sh processes $ENV fine if it has been set inside ~/.profile like:

	ENV=${HOME}/.env; export ENV

However, it fails to source $ENV in this case:

	export ENV=${HOME}/.env

>How-To-Repeat:

Use:

	export ENV=${HOME}/.env

in your ~/.profile, and re-invoke another level of sh(1).  $ENV won't
be read.  Now invoke any other Bourne-alike shell (pdksh, ksh93,
bash), it will process $ENV correctly.

>Fix:
	
Not known.

>Release-Note:
>Audit-Trail:

From: Steve Price <sprice@hiwaay.net>
To: un_x@hotmail.com
Cc: FreeBSD-gnats-submit@freefall.freebsd.org,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Mon, 10 Mar 1997 23:10:57 -0600

 steve howe wrote:
 > 
 > >Number:         2934
 > >Category:       bin
 > >Synopsis:       sh(1) has problems with $ENV
 > 
 > /bin/sh in any FreeBSD system so far.
 > 
 > >Description:
 > 
 > /bin/sh processes $ENV fine if it has been set inside ~/.profile like:
 > 
 >         ENV=${HOME}/.env; export ENV
 > 
 > However, it fails to source $ENV in this case:
 > 
 >         export ENV=${HOME}/.env
 > 
 > >How-To-Repeat:
 > 
 > Use:
 > 
 >         export ENV=${HOME}/.env
 > 
 > in your ~/.profile, and re-invoke another level of sh(1).  $ENV won't
 > be read.  Now invoke any other Bourne-alike shell (pdksh, ksh93,
 > bash), it will process $ENV correctly.
 > 
 
 I tried this and it didn't appear to work at first, but I believe
 it is because of this.
 
 steve[~]$ grep steve /etc/passwd
 steve:*:1000:1000:Steve Price:/home/steve:/bin/bash
 steve[~]$ echo $ENV
 /home/steve/.bashrc
 steve[~]$ cat /home/steve/.bashrc
 steve[~]$ cat /home/steve/.profile 
 export ENV=${HOME}/env-stuff
 echo ~/.profile
 steve[~]$ cat /home/steve/env-stuff
 echo "Yep I'm here!"
 steve[~]$ sh
 \u[\w]\$ exit
 steve[~]$ 
 
 But after I change my login shell to /bin/sh or do a
 export ENV=${HOME}/env-stuff.  It works as suspected.  It appears
 to be a problem in that ~/.bash_profile is getting sourced and
 ENV is picked up from there.  The reason that this would matter
 is that ~/.profile (or ~/.bash_profile for bash's case) is only
 getting sourced when it is started as a login shell.  So just
 typing 'sh' will not source ~/.profile, but will source $ENV (which
 was set by your login shell) if your euid == uid && egid == gid.
 
 Could this be the case with you as well?
 
 Steve
 
 > >Fix:
 > 
 > Not known.
 > 
 > >Audit-Trail:
 > >Unformatted:
 > [This PR sent by joerg on behalf of Steve who doesn't have a good
 > enough IP connectivity.]

From: Stephen McKay <syssgm@devetir.qld.gov.au>
To: Steve Price <sprice@HiWAAY.net>
Cc: freebsd-gnats-submit@freebsd.org, syssgm@devetir.qld.gov.au
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Tue, 11 Mar 1997 19:12:28 +1000 (EST)

 Steve Price <sprice@HiWAAY.net> wrote:
 
 > steve howe wrote:
 > > 
 > > Use:
 > >         export ENV=${HOME}/.env
 > > 
 > > in your ~/.profile, and re-invoke another level of sh(1).  $ENV won't
 > > be read.  Now invoke any other Bourne-alike shell (pdksh, ksh93,
 > > bash), it will process $ENV correctly.
 > > 
 
 [Description of confusion between bash use of $ENV and sh use of $ENV elided.]
 
 > Could this be the case with you as well?
 
 Well my view on this is that $ENV processing in /bin/sh is a dumbass idea,
 and should be expunged immediately.  Is it mandated by POSIX?  Then send
 them a rude letter and delete it anyway.
 
 Is $ENV there to scare off the last few people who use the shell for scripts?
 It's a perl plot, right?  "We will trick those foolish sh users!  Ha! Ha!
 Just look at what we can do to them now:"
 
 $ cat silly-bits
 echo "Hello from ENV processing"
 echo "This is where people put stupid things that break system scripts"
 ls() { /bin/ls -sF $*; }
 $
 $ export ENV=`pwd`/silly-bits
 $
 $ cat serious-prog
 #! /bin/sh
 PATH=/bin:/usr/bin
 echo "This had better be formatted correctly, or things will break!"
 ls s*
 $
 $ ./serious-prog
 Hello from ENV processing
 This is where people put stupid things that break system scripts
 This had better be formatted correctly, or things will break!
 1 serious-prog* 1 silly-bits
 $
 
 Ouch!  What can you depend on any more, even with PATH set?  It's become
 that much harder to write shell scripts.
 
 Oh, and while you're deleting $ENV processing, I'm pretty unhappy with /bin/sh
 being bloated with history editing.  I'll be testing -DNO_HISTORY, and will
 put that in my /etc/make.conf if it works.
 
 Yours in frump,
 
 Stephen.

From: Stephen McKay <syssgm@devetir.qld.gov.au>
To: " steve  howe" <un_x@hotmail.com>
Cc: freebsd-gnats-submit@freebsd.org, syssgm@devetir.qld.gov.au
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Tue, 11 Mar 1997 20:35:46 +1000 (EST)

 " steve  howe" <un_x@hotmail.com> pretended to write:
 
 >/bin/sh processes $ENV fine if it has been set inside ~/.profile like:
 >
 >	ENV=${HOME}/.env; export ENV
 >
 >However, it fails to source $ENV in this case:
 >
 >	export ENV=${HOME}/.env
 
 I found the original stuff in -hackers, and just to prove that I'm capable
 to having a bet each way on each problem :-) I recreated his real problem:
 
 Under 2.1.5 (at least; can't check anything else right now):
 
 $ cat ~/junk
 echo Hi from junk
 $ export ENV=~/junk
 $ echo $ENV
 ~/junk
 $ sh -c date
 Tue Mar 11 20:29:58 EST 1997
 $ ENV=~/junk
 $ export ENV
 $ echo $ENV
 /home/syssgm/junk
 $ sh -c date
 Hi from junk
 Tue Mar 11 20:30:42 EST 1997
 $
 
 So, ~ expansion happens differently in the two places.  Fix one.
 
 Of course, when $ENV processing is removed, this will no longer be a
 problem. :-)  (Am I the only one to heave when 'sh -c prog' executes $ENV?)
 
 Stephen.

From: Gareth McCaughan <gjm11@dpmms.cam.ac.uk>
To: freebsd-bugs@freebsd.org
Cc:  Subject: Re: bin/2934: sh(1) has problems with $ENV 
Date: Tue, 11 Mar 1997 12:53:06 +0000

 > >Description:
 > 
 > /bin/sh processes $ENV fine if it has been set inside ~/.profile like:
 > 
 > 	ENV=${HOME}/.env; export ENV
 > 
 > However, it fails to source $ENV in this case:
 > 
 > 	export ENV=${HOME}/.env
 
 This is not quite correct. If you use this idiom, sh behaves
 correctly. If, however, you use ~ instead of $HOME, then the
 tilde doesn't get expanded when you do "export ENV=~/foo",
 but it does when you do "ENV=~/foo".
 
 Then, when your new sh starts up and reads ENV, it finds the
 variable correctly in both cases; however, its ENV-processing
 code doesn't interpret the ~ and so it fails to find the file.
 
 My reading of the sh(1) manpage is that tilde expansion *should*
 happen, and that the ENV-processing code *should not* try to
 do tilde expansion, but I am no sh(1) guru so I speak subject
 to correction.
 
 If my reading is correct, then (1) the same problem also affects
 the "readonly" command, and (2) I believe that the following patch
 fixes both problems. (It's relative to the version of sh in 2.2-GAMMA.)
 
 I repeat that I am not a sh(1) guru, so this ought to be checked
 by someone who knows more than I do about this stuff. I've moved
 the "locate command" code so that it happens as soon as it's known
 what the command is; then, if the command is "export" or "readonly",
 the args are expanded like initial var=val pairs are.
 
 ---------- patch begins ----------
 *** eval.c.orig	Tue Nov 12 19:23:44 1996
 --- eval.c	Tue Mar 11 12:47:04 1997
 ***************
 *** 594,600 ****
   	char **argv;
   	int argc;
   	char **envp;
 ! 	int varflag;
   	struct strlist *sp;
   	int mode;
   	int pip[2];
 --- 594,600 ----
   	char **argv;
   	int argc;
   	char **envp;
 ! 	int doing_cmd, setting_cmd;
   	struct strlist *sp;
   	int mode;
   	int pip[2];
 ***************
 *** 607,612 ****
 --- 607,613 ----
   	struct localvar *volatile savelocalvars;
   	volatile int e;
   	char *lastarg;
 + 	char *path=pathval();
   #if __GNUC__
   	/* Avoid longjmp clobbering */
   	(void) &argv;
 ***************
 *** 620,641 ****
   	setstackmark(&smark);
   	arglist.lastp = &arglist.list;
   	varlist.lastp = &varlist.list;
 ! 	varflag = 1;
   	oexitstatus = exitstatus;
   	exitstatus = 0;
   	for (argp = cmd->ncmd.args ; argp ; argp = argp->narg.next) {
   		char *p = argp->narg.text;
 ! 		if (varflag && is_name(*p)) {
   			do {
   				p++;
   			} while (is_in_name(*p));
 ! 			if (*p == '=') {
 ! 				expandarg(argp, &varlist, EXP_VARTILDE);
   				continue;
   			}
   		}
 ! 		expandarg(argp, &arglist, EXP_FULL | EXP_TILDE);
 ! 		varflag = 0;
   	}
   	*arglist.lastp = NULL;
   	*varlist.lastp = NULL;
 --- 621,660 ----
   	setstackmark(&smark);
   	arglist.lastp = &arglist.list;
   	varlist.lastp = &varlist.list;
 ! 	doing_cmd = 1; setting_cmd = 0;
   	oexitstatus = exitstatus;
   	exitstatus = 0;
   	for (argp = cmd->ncmd.args ; argp ; argp = argp->narg.next) {
   		char *p = argp->narg.text;
 ! 		if ((doing_cmd || setting_cmd) && is_name(*p)) {
   			do {
   				p++;
   			} while (is_in_name(*p));
 ! 			if (*p == '=') {	
 ! 				expandarg(argp,
 ! 				          setting_cmd ? &arglist : &varlist,
 ! 				          EXP_VARTILDE);
 ! 				if (doing_cmd) {
 ! 					static const char PATH[] = "PATH=";
 ! 					char *s = ((struct strlist *)varlist.lastp)->text;
 ! 					if (!strncmp(s, PATH, sizeof(PATH)-1))
 ! 						path = s + sizeof(PATH) - 1;
 ! 				}
   				continue;
   			}
   		}
 ! 		{
 ! 	                expandarg(argp, &arglist, EXP_FULL | EXP_TILDE);
 ! 	                if (doing_cmd) {
 ! 		                char *s = ((struct strlist *)arglist.lastp)->text;
 ! 	                        /* Now locate the command. */
 ! 	                        find_command(s, &cmdentry, 1, path);
 ! 	                        /* Does it require us to grok future var=val pairs? */
 ! 	                        if (cmdentry.cmdtype == CMDBUILTIN && cmdentry.u.index == EXPORTCMD)
 ! 	                                setting_cmd=1;
 ! 	                }
 ! 	                doing_cmd = 0;
 ! 		}
   	}
   	*arglist.lastp = NULL;
   	*varlist.lastp = NULL;
 ***************
 *** 675,692 ****
   		cmdentry.cmdtype = CMDBUILTIN;
   		cmdentry.u.index = BLTINCMD;
   	} else {
 - 		static const char PATH[] = "PATH=";
 - 		char *path = pathval();
 - 
 - 		/*
 - 		 * Modify the command lookup path, if a PATH= assignment
 - 		 * is present
 - 		 */
 - 		for (sp = varlist.list ; sp ; sp = sp->next)
 - 			if (strncmp(sp->text, PATH, sizeof(PATH) - 1) == 0)
 - 				path = sp->text + sizeof(PATH) - 1;
 - 
 - 		find_command(argv[0], &cmdentry, 1, path);
   		if (cmdentry.cmdtype == CMDUNKNOWN) {	/* command not found */
   			exitstatus = 1;
   			flushout(&errout);
 --- 694,699 ----
 ----------- patch ends -----------
 
 -- 
 Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
 gjm11@dpmms.cam.ac.uk  Cambridge University, England.

From: " steve  howe" <un_x@hotmail.com>
To: sprice@hiwaay.net
Cc: FreeBSD-gnats-submit@freefall.freebsd.org,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Fri, 14 Mar 1997 09:02:22 -0800 (PST)

 >Date: Mon, 10 Mar 1997 23:10:57 -0600
 >From: Steve Price
 >To: un_x@hotmail.com
 >CC: FreeBSD-gnats-submit@freefall.freebsd.org,
 >Subject: Re: bin/2934: sh(1) has problems with $ENV
 >steve howe wrote:
 >>
 >> >Number:         2934
 >> >Category:       bin
 >> >Synopsis:       sh(1) has problems with $ENV
 >>
 >> /bin/sh in any FreeBSD system so far.
 >>
 >> >Description:
 >>
 >> /bin/sh processes $ENV fine if it has been set inside ~/.profile like:
 >>
 >>         ENV=${HOME}/.env; export ENV
 >>
 >> However, it fails to source $ENV in this case:
 >>
 >>         export ENV=${HOME}/.env
 >>
 >> >How-To-Repeat:
 >>
 >> Use:
 >>
 >>         export ENV=${HOME}/.env
 >>
 >> in your ~/.profile, and re-invoke another level of sh(1).  $ENV won't
 >> be read.  Now invoke any other Bourne-alike shell (pdksh, ksh93,
 >> bash), it will process $ENV correctly.
 >>
 >
 >I tried this and it didn't appear to work at first, but I believe
 >it is because of this.
 >
 >steve[~]$ grep steve /etc/passwd
 >steve:*:1000:1000:Steve Price:/home/steve:/bin/bash
 >steve[~]$ echo $ENV
 >/home/steve/.bashrc
 >steve[~]$ cat /home/steve/.bashrc
 >steve[~]$ cat /home/steve/.profile
 >export ENV=${HOME}/env-stuff
 >echo ~/.profile
 >steve[~]$ cat /home/steve/env-stuff
 >echo "Yep I'm here!"
 >steve[~]$ sh
 >\u[\w]\$ exit
 >steve[~]$
 >
 >But after I change my login shell to /bin/sh or do a
 >export ENV=${HOME}/env-stuff.  It works as suspected.  It appears
 >to be a problem in that ~/.bash_profile is getting sourced and
 >ENV is picked up from there.  The reason that this would matter
 >is that ~/.profile (or ~/.bash_profile for bash's case) is only
 >getting sourced when it is started as a login shell.  So just
 >typing 'sh' will not source ~/.profile, but will source $ENV (which
 >was set by your login shell) if your euid == uid && egid == gid.
 >
 >Could this be the case with you as well?
 >
 i'm not sure exactly what you want to know from me - but i am only
 using "sh" - no other shells.  
 >
 >>
 >> Not known.
 >>
 >> >Audit-Trail:
 >> >Unformatted:
 >> [This PR sent by joerg on behalf of Steve who doesn't have a good
 >> enough IP connectivity.]
 >
 
 ---------------------------------------------------------
 Get Your *Web-Based* Free Email at http://www.hotmail.com
 ---------------------------------------------------------
Responsible-Changed-From-To: freebsd-bugs->cracauer 
Responsible-Changed-By: johan 
Responsible-Changed-When: Mon Oct 30 10:20:22 PST 2000 
Responsible-Changed-Why:  
Over to sh(1) maintianer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2934 

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Tue, 19 Nov 2002 02:02:48 -0500

 this has had no traffic since 2000, there is also a patch included
 at one point, can this be closed?
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Mon, 17 Feb 2003 00:13:09 -0500

 This PR can be closed
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/2934: sh(1) has problems with $ENV
Date: Thu, 6 Mar 2003 01:46:29 -0500

 this pr can be closed
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: insane@wreck.org
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: bin/2934: sh(1) has problems with $ENV
Date: Tue, 29 Apr 2003 19:03:52 -0400

 This PR can be closed
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu
Responsible-Changed-From-To: cracauer->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 26 19:37:53 GMT 2004 
Responsible-Changed-Why:  
With permission, reassign this to the main pool. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2934 
State-Changed-From-To: open->closed 
State-Changed-By: gabor 
State-Changed-When: Mon Dec 25 21:33:38 UTC 2006 
State-Changed-Why:  
This issue seems to be fixed on 6.1, or at least I can't reproduce it. 
If you still experience this issue on a recent FreeBSD release, 
please feel free to submit a follow-up to this PR and we will find out 
how to solve it. Thanks for your effort on making FreeBSD better. 

Regards, 
Gabor Kovesdan 


Responsible-Changed-From-To: freebsd-bugs->gabor 
Responsible-Changed-By: gabor 
Responsible-Changed-When: Mon Dec 25 21:33:38 UTC 2006 
Responsible-Changed-Why:  
This issue seems to be fixed on 6.1, or at least I can't reproduce it. 
If you still experience this issue on a recent FreeBSD release, 
please feel free to submit a follow-up to this PR and we will find out 
how to solve it. Thanks for your effort on making FreeBSD better. 

Regards, 
Gabor Kovesdan 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2934 
>Unformatted:
[This PR sent by joerg on behalf of Steve who doesn't have a good
enough IP connectivity.]

