just try to create it and interpret any error appropriately.
this fixes a problem where multiple "mkdir -p" processes can race,
with the loser returning a spurious error.
- ansification
- format of output of jobs command (etc)
- job identiers %+, %- etc
- $? and $(...)
- correct quoting of output of set, export -p and readonly -p
- differentiation between nornal and 'posix special' builtins
- correct behaviour (posix) for errors on builtins and special builtins
- builtin printf and kill
- set -o debug (if compiled with DEBUG)
- cd src obj (as ksh - too useful to do without)
- unset -e name, remove non-readonly variable from export list.
(so I could unset -e PS1 before running the test shell...)
While a hard link to a symbolic link is not ruled out by POSIX-2001,
the ln(1) utility (sans -s) is to perform equivalent to the link(2)
function on its operands, which includes the resolution of symbolic
links in source_file arguments.
> The wrong process is aborting when variable assignment fails
> in the vfork path. So the following command fails to execute
> the second echo (shown here with the correct output).
>
> $ (readonly r; r= /bin/echo a; echo b)
> r: is read only
> b
>
> fix: defer the mklocal() to the child shell.
> Also 'jobs' fails in a non-interactive shell.
> In showjobs(), the code that puts the process back into its
> own process group should only be run if the shell is actually
> doing job control - eg if 'mflag' is set.
$ /fred # non existant command
$ ^C # stops working
He says:
Ok the extra INTOFF is the one in exverror().
In almost all cases this doesn't matter because the longjmp()s
all end up in main() and the FORCEINTON call sorts it out
for the next command.
(There are a significant number of INTON/OFF mismatches through
the error paths...)
In any case the above failure can be 'fixed' by changing 2 (I think
they are both needed) INTON calls to FORCEINTON within evalcommand.
The following patch seems to work:
We should really look in the code and fix the INTON->INTOFF pairs.
and /usr/bin/cpio (/bin/cpio). The pathname of tar(1) is hard-coded
into things like binary packages, and thus must be kept around
for backward compatibility.
