Date: Thu, 26 Apr 2018 11:56:09 +0200
From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
Message-ID: <5ae1a239.3rdvpcuahhnmbtgl%joerg.schill...@fokus.fraunhofer.de>
| > A4. Option flag 'i' in $- to see if shell is interactive.
| The flag "i" has a different purpose than what you like. "i" forces the
shell
| to become interactive. What you are looking for is the "s" flag.
In a later message you added:
| Historic practice however was to have "s" in $- for interactive shells.
's' means reading stdin, which you're right, is more or less guaranteed
for an interactive shell, but is also set for things like
echo ls | sh
where the shell is not interactive. These days everyone sets the 'i'
flag for interactive shells, and bug 1039 adds it to posix, so this one
is simply done already.
[ trailing whitespace in $((var)) variables]
| since the simplest way to check for a valid number is to check whether the
| number ends right, this may be a problem depending on the parser.
It really is fairly easy - the NetBSD sh used not to allow trailing whitespace,
but does now (since Martijn brought it to my attention.) The only slight
extra hitch is to not allow vars that contain only whitespace (and are not
empty). ie:
var=' '; : $((var))
is not sane, and should continue to be rejected.
This is not really even a change, what is required is a "valid integer
constant" in the variable (with an optional leading sign) - nothing says
whether whitespace is allowed, before or after, or not - but as long as
the number is there (with its optional sign) whitespace can just be
ignored. It would be useful to make at least ignoring leading whitespace
required now (since everyone already does that) and to make ignoring
trailing whitespace a "future direction" so shells add the couple of extra
lines that are needed, and a later std rev can make that required as well.
| > B3. Elements of a pipeline (except the last) run in current environment.
| >
| This was intentionally not part of the standard.
I think you are misunderstanding the request - it was not to require pipelines
to run in the same shell env, but to forbid it, except for the final element.
| The Bourne Shell did run all elements in a subshell because that (even
though
| slow) allowed to implement pipes with few code, which is important for a
PDP-11.
Yes, so does everything else (modulo the final element) - but posix allows
any of thesimple-commands in the pipeline to be executed in the current shell
env - which mean that script writers need to deal with the possibility that
some shell might actually implement that.
| What POSIX shell do you believe is a problem?
He doesn't believe any are, that's the point, it is only the std that is the
problem.
| > B4. Shell may exit if command not found. (XCU 2.8.1, last row in table)
| For some commands you need to do that (e.g. if you like to check whether
| "set -o posix" is usable.
Huh? What shell, anywhere, exits on command not found ? (that is, not
counting when the command that was not found was the last, and not when
it was run via "exec").
Again, it is that the std allows it, for non-interactive shells that is a
problem, as it means that instead of code like
cmd || error "cmd failed or is not installed"
one must always do
( cmd ) || error "..."
Basically - every command must be run in a sub-shell, just in case
it does not exist - if the script is to continue after.
No-one writes code like that, and no actual shells require it.
kre
