Changelog from AN-2021-01-05:
- Bourne Shell: When we introduced ${.sh.path} in February 2020, we did
use the "new" and POSIX-only function realpath() that is not present
on e.g. Ultrix. We now use abspath() from libschily if realpath() is
missing.
Note that abspath() is better than realpath(), as it supports path
names longer than PATH_MAX, but since ${.sh.path} is only used to
return the absolute pathname for the current shell binary, this is
not a problem and on the other side, we can avoid linking against
libschily this way, so shell scripting with lazy linking is faster
since less libraries need to be linked at startup.
Changelog from AN-2021-04-21:
- Bourne Shell: gmatch.c: The new version no longer aborts with an
illegal multi byte sequence as "no match". As a result, the "*"
now again matches any filename - even if the filename contains an
illegal multi-byte sequence. This is a problem that did not exist
on the original Bourne Shell from Solaris that used gmatch() from
the AT&T libgen, but since we added our private portable gmatch.c.
to get better portability.
Thanks to Stephane Chazelas for reporting the problem related to
multi-byte to wide character conversion and illegal multi byte
sequences in the case statement and filesystem globbing.
- Bourne Shell: word.c::readwc() no longer uses prwc() but rather
a loop on the original multi-byte stream to print the "set -v"
output. This permits to output the original input data in any
case instead of stumbling over illegal multi-byte sequences.
Thanks to Stephane Chazelas for reporting the general problem
with input byte sequences that cause an EILSEQ error.
- Bourne Shell: struct fileblk now remembers lastwc and the related
input string as fileblk->mbs[] in order to avoid incorrect
conversions via wctomb() in case that the input wide char was a
result from an EILSEQ conversion and thus has no related multi
byte string.
An important visible result of that change is that input read
by the builtin command read(1) correctly forwards input that
caused an EILSEQ error.
It could not be verified whether this covers all possible similar
cases, but it is at least very close to a completely correct
solution.
Thanks to Stephane Chazelas for reporting the general problem
with input byte sequences that cause an EILSEQ error.
- Bourne Shell: xec.c: Cstyle changes
- Bourne Shell: the Copyright messages now mention 2021
1aa3e09a6e