this change broke abortion on failure to read input, was not
needed for gcc warnings and is the fault of Intel’s compiler
this should fix the other busy-loop problem occuring only on
GNU/Linux so far – 10x spaetzle@freewrt.o for pointing me to
the problem; reproduced on my work craptop
from netbsd via oksh
we had the NULL pointer deref already fixed
• avoid a bogus not-setting the return value of edit.c:x_file_glob()
introduced by the above change in oksh
• escape ? as well (but not ] because that’s wrong)
reminded by cbiere@netbsd via oksh
• Unsetting a non-existent variable is not an error. See
http://www.opengroup.org/onlinepubs/009695399/utilities/unset.html
report from Arkadiusz Miskiewicz; fixed based on
http://cvs.pld-linux.org diff via oksh but modified slightly
• Be more smart waiting for input for non-interactive scripts. Fix
based on a diff from debian: see their bug#296446 (via oksh)
modified slightly
this also fixes cnuke@’s “mksh busy loop” problem, for which I never
received a bug report, but the Debian bug page contains a set of two
scripts to reproduce this before (and no longer after) this commit
• some KNF
• bump version
In contrast to AT&T ksh93, its semantics are like GNU bash in that it ap-
pends the current working directory to the search path; it is implemented
as a shell alias instead of enhancing funcs.c:shbuiltins[] like in ksh93.
delivered to the process
• regression test by Clint Pachl, verified against Debian ksh93 by me
• place to fix it in the code discovered by Otto Moerbeek
namely Dr. Robert “Pfeffer” Arnold (in this case, in FreeWRT), make
a half-completed attempt at implementing ${foo:2:3} substring evals
(of course, negatives can't work right now and that the numbers are
in face expressions is something I only read later too – this is to
be revisited later, but it's already late)
don't depend on this behaviour yet though
if someone wants to add more regression tests, feel free to…
is a compromise anyway; these lunox people will have to live with that, too
many existing korn shell alike scripts depend on it even if not on the full
korn shell syntax availability (note: this doesn't mean using these in some
script with #!/bin/sh is ok)
mksh was configured to have utf-8 mode “always on” (because it's
really only always on for interactive shells); setting it to really
always on would break the other half of this regression test, so
do the optimisation only if MKSH_SMALL
do not start with a "#!shell" sequence” part of mksh(1) true again; this
was probably lost in mksh R21 or so when I decided/saw that our kernel
always parses shebang lines (code written myself, not taken from pdksh
again or MirBSD kernel, but verified against both)
• bom+shebang execution now works, no need setting EXECSHELL in the test
• bump version
starting with an UTF-8 BOM before the shebang can be executed correctly;
this would succeed if either mksh parses the shebang line instead of re-
lying on $EXECSHELL or the kernel supports it
bsiegert@ ok's my attempts to fix this
given to execute, standard input (interactive or not), via -c command line
argument, or after “eval”, but not for $(…) comsubs, at the beginning of a
subsequent line, or within a line, etc.); regression test for it
idea during my “week off” (despite the pain), bsiegert@ thinks it's good –
and utf-8 capable tools ought to be able to do this anyway
tg