Re: standards/42828: Almquist shell always evaluates the contents of ${ENV} even if non-interactive

[Richard Hansen <rhansen%bbn.com@localhost>]

The following reply was made to PR standards/42828; it has been noted by GNATS.

From: Richard Hansen <rhansen%bbn.com@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, standards-manager%NetBSD.org@localhost, 
 netbsd-bugs%NetBSD.org@localhost
Subject: Re: standards/42828: Almquist shell always evaluates the contents
 of ${ENV} even if non-interactive
Date: Fri, 19 Feb 2010 14:36:53 -0500

 >> Cross-platform scripts can't rely on NetBSD's nonstandard behavior,
 > 
 > One of us is confused about what $ENV is for?   What scripts are ever going 
 > to 
 > set that (clear(unset) it perhaps, but set it?)
 
 My .profile sets ENV.  (By "script" I meant a file containing 
 environment setup commands.  That was not the best word to use, but I 
 couldn't think of a better word and I thought that context would make 
 the meaning clear.  I apologize for the imprecision.  In the future I'll 
 use "script" to only refer to executable files beginning with the 
 '#!/bin/sh' shebang.)
 
 > Particularly the way you expect it to work
 
 It's not just me; everyone under the impression that NetBSD conforms to 
 POSIX also expects it.
 
 > - where it applies only to interactive shells, which isn't 
 > something many scripts ever care about.
 > 
 > Do you have a real example of something that breaks (other than a 
 > conformance 
 > test) because of this?   That is, excluding user environments, we know 
 > they're 
 > different.
 
 Why exclude user environments?  The purpose of ${ENV} is to customize 
 the user's interactive shell.
 
 This bug broke my dot files, which is how I discovered it.  I just 
 installed NetBSD for the first time the other day, and my first 
 experience was watching it lock up after copying my dot files from a 
 Linux machine.  The freeze was thanks to a fork bomb that wouldn't have 
 happened had NetBSD's shell conformed to the POSIX spec.  Ctrl-C 
 eventually worked, but only after several minutes of unwinding the 
 process stack.
 
 >> but I believe the long-term benefit from standards compliance will outweigh 
 >> the short-term pain.
 > 
 > Better long term benefit would be to convince the standard to be rational.
 
 Good point.
 
 > We don't achieve that (not any hope of achieving that) if everyone just does 
 > what they say because they say it, and not because it is the right thing to 
 > do.
 
 Likewise, the standard won't change because the NetBSD community 
 silently resists it; someone has to fight for change.  I don't have the 
 time to champion the cause.  Would you be willing to take this up with 
 the POSIX working group?
 
 > Following the standards is great when it is a matter of a choice between 
 > two ways of which we could pick either - and sometimes when it is a matter 
 > of 
 > adding something that we don't really see the need for, but does no real 
 > harm 
 > to have - but never when their design is flawed.
 
 I agree that the POSIX design is limited relative to the NetBSD design, 
 but I would not call it flawed.  Suboptimal perhaps, but not flawed. 
 Flawed implies that there are legitimate use cases that are not 
 supported, but I have not yet come across any such use cases.  Can you 
 provide an example where a user needs ${ENV} evaluated upon invocation 
 of every non-interactive shell?
 
 Perhaps the flaw is in NetBSD's design:  The ${ENV} file can arbitrarily 
 modify the shell execution environment (change the working directory, 
 modify positional parameters, close file descriptors, trap signals, 
 define functions, set shell options, etc.).  This means that shell 
 script writers can't rely on a consistent initial environment.  It is 
 doubtful this would be a significant problem in practice, but in theory 
 this could lead to bugs that appear to be in a script file but are 
 actually caused by the user's ${ENV} file.
 
 
 I want to pause and wax introspective for a moment.  A number of BSD 
 fans give Linux users a hard time, but due to this bug my first 
 impression was that NetBSD is half-baked; that it fails to conform to 
 even the pedestrian parts of POSIX.  I know that bugs happen so I'm 
 willing to forgive flaws and even contribute to fixes, but only if the 
 community respectfully deals with legitimate user complaints.  The 
 antagonistic response I've received to this bug is disheartening and 
 makes me disinclined to contribute to NetBSD in the future.
 
 -Richard