The same results can be achieved by prepending a special directory to PATH and populating that directory with custom versions of standard commands.No, that doesn't work, built in commands are executed before commands found in $PATH, so that doesn't work to override stuff like test, let alone the built in commands that can't go in $PATH (like cd) which happens to be one of the commands I most often want to override. That can be done by defining a cd() function, and that works in ${ENV}.
Ah ha! That's what I was looking for. I can see how overriding built-ins could be useful, and the POSIX design makes it impossible. Now I see the benefit of evaluating a file at the start of non-interactive shells (I just couldn't think of a practical use for the non-standard behavior).
So, my opinion is that NetBSD's functionality should be preserved, just moved elsewhere (such as a different environment variable) so that it doesn't conflict with POSIX.
* working directory: Initially the current directory matches the working directory of the invoker. If the user adds 'cd "${HOME}"' to the ${ENV} file, then every shell script will assume it was invoked from ${HOME}.Of course, and it would be, and if that's what the user wanted to happen (which we can assume they must have when they put that in ${ENV}) then what's the problem?
I'm coming from the perspective of users that expect POSIX compliance. They might add 'cd "${HOME}"' not realizing that it also affects shell scripts.
there's also no real reason to anticipate that someone will do set -C in ${ENV} (outside a test for an interactive shell).
I think there is a reason: users like me that assume POSIX compliance and fail to test for an interactive shell. They might not realize that errors in 3rd party scripts are their fault. They might not even see the errors if the script is executed by an X application.
Local system documentation trumps the POSIX spec every time.
Good point. But aren't users expecting POSIX more and more? Perhaps it's time to take another small step toward compliance.
-Richard