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