Log message:
shells/pbosh: Update to 20210421

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

Log message:
pbosh: Update to 20201125

Changelog from AN-2020-11-04:
- Makefile system: include/schily/nlsdefs.h no longer by default defines
  the macro __() because this is in conflict with definitions that are
  present in the system include files from newer HP-UX versions.

  Thanks to Rudi Blom for reporting.

- Bourne Shell: If a background job did finish during an implicit wait
  for a foreground job, the exit code for the background job was lost.

  This was caused by a forgotten call to statjob(jp, &si, 0, 0) in
  the function waitjob();

  Thanks to Koichi Nakashima for reporting.

- Bourne Shell: The changes from 2020-10-09 to keep the exit code from
  jobs like "(sleep 10; exit 17)&" in the job list, caused a \ 
command like

      cat /etc/termcap |more

  to stop after the first page of output because "more" died from trying
  to read the answer for continuing the output as it was not in the
  current foreground process group from the tty. This was the result of
  a forgotten call to monitor = ismonitor(xflags); in xec.c

- Bourne Shell: The changes from 2020-10-09 to keep the exit code from
  jobs like "(sleep 10; exit 17)&" could cause some wait commands \ 
to hang
  infinitely because the job list had an endless loop. The new code
  avoids to create the endless loop in the job list.

  Thanks to Koichi Nakashima for reporting.

- Bourne Shell: The changes for jobcontrol in schily-2020-10-09 could.
  cause bosh to dump core with the builtin fg(1) command because "thisjob".
  was a NULL pointer.

  We add a new lastthisjob variable to work around this problem.

  Thanks for Noci Sonack for reporting.

- bsh/Bourne Shell: str2sig() has been enhanced to support e.g.
  RTMIN+20 or RTMAX-20 as alias on platforms with 30 RT signals.

  Note that this currently only works on non-POSIX platforms like Linux
  where our private implementation is used. On Solaris, this would need
  to wait until compatibility to POSIX issue 8 has been implemented
  in the libc from Solaris.

Changelog from AN-2020-11-25:
- Makefile System: Added support for MacOS on arm64

  Thanks to a hint from Ryan Schmidt from macports

  Note that due to outstanding replies to recent changes in configure,
  it could up to now not be verified that all configure tests now work in
  a way that results in correct overall results. See below for an in
  depth report on the changes.

- Makefile System: autoconf (config.guess & config.sub) now supports
  the new arm64 Apple systems.

  Thanks to Ryan Schmidt from macports for provinding the needed uname(1)
  output.

- Makefile System: Added a new shell script "autoconf/uname" that helps
  to create shell scrips that allow to emulate an alien host system in
  order to test the correct behavior of configure.guess and configure.sub
  on the main development platform.

  This helps to adapt configure.guess and configure.sub to new platforms
  in the future.

- Makefile System: The new clang compiler as published with the upcomming
  ARM macs has been preconfigured with

      -Werror -Wimplicit-function-declaration

  as the default behavior and thus is in conflict with the existing base
  assumption of the autoconf system that minimalistic C-code used for
  compile/link allows to check for the existence of a specific function
  in libc without a need to know which system #include file is used to
  define a prototype for that function.

  This clang version, as a result of this default, behaves like a C++
  compiler and aborts if a function is used with no previous function
  prototype. This caused most of the existing autoconf test to fail with
  error messages about missing prototypes.

  We implemented a workaround using these methods for the identified
  problems:

  - Most of the exit() calls in the various main() functions have
    been replaced by return() to avoid a need to
    #include <stdlib.h> in special since these test may be the
    case for layered tests that #include files from the higher
    level parts.

  - Many autoconf tests programs now #include more system include
    files, e.g. stdlib.h and unistd.h to avoid missing prototype
    errors. This cannot reliably be done in tests that are used as
    a base for higher level tests where the high level test
    #includes own system include files, since older platforms do
    not support to #include the same file twice.

    So this is tricky...

  - A test for a Linux glibc bug caused by incorect #pragma weak
    usage inside glibc that prevents one or more functions from
    ecvt()/fcvt()/gcvt() from being usable outside glibc now uses
    hand-written prototypes for some of the libc interface
    functions in order to avoid using the system includes. If we
    did not do that, we could not use ecvt()/fcvt()/gcvt() on
    MacOS anymore.

  Thanks to Ryan Schmidt from macports for reporting and for the given
  help that was needed for remote debugging.

  Please send the needed feedback on whether the current state of the
  configure script results on correct autoconf results on the M1 Macs.

Log message:
shells/pbosh: Update to 20201009

New features with AN-2020-09-04:
- autoconf: congig.guess: FreeBSD on 64 bit ARM returns arm64 from
  uname -m; this was previously not supported and rejected by config.sub.
  We now convert "arm64" into "aarch64" in config.guess to \ 
get the usual
  expected results.

- Makefile system: RULES/rules.env The environment variables FIGNORE,
  LD_LIBRARY_PATH LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 are now
  unexported from the enviroment.

  In special FIGNORE is dangerous, as it is frequently used by bash
  users but tells ksh93 to modify it's behavior with "echo *" and
  this may cause strange things with our makefiles in case that
  /bin/sh is ksh92. This applies e.g. to Oracle Solaris 11 and
  OpenSolaris.

- Bourne Shell: added $(RM) -f $(DEST_DIR)$(INSBASE)/xpg4/bin/bosh
  to the Makefile in the commands before creating the symlink
  xpg4/bin/bosh to bosh to permit to call "make install" more than
  once without causing an error.

- Bourne Shell: version.h now contains a new version date.

New features with AN-2020-10-09:
- autoconf: Added support for newer HP-UX versions on Itanium.

  Thanks to Rudi Blom for reporting and making a change proposal.

- Bourne Shell: The "wait" builtin is now POSIX compliant and returns 127
  in $? in case that a process id to be waited for does not exist.

- Bourne Shell: The exit code retrieved by $/ no longer is masked by 0xFF
  when this code originates from a wait(1) call.

  Thanks to Koichi Nakashima for reporting

- Bourne Shell: The man page has been enhanced for a better description
  of the exit code constraitns.

  Thanks to Koichi Nakashima for reporting

- Bourne Shell: The exit code from background jobs is now kept until
  the builtin wait(1) is called.

  Note that this introduces the need to call "wait" from time to time
  in order to free shell job management resources.

  Thanks to Koichi Nakashima for reporting

- Bourne Shell: The changes to keep exit codes for background jobs
  caused problems that triggered a SIGSEGV in the shell with jobs like:

      (sleep 10; exit 17)&

  This needed a restructuring in the job management implementation.

- Bourne Shell: Since the next POSIX standard will make it optional
  whether sig2str() and str2sig() deal with entries for "EXIT" / 0,
  we enhanced the trap2str() and str2trap() interfaces to handle
  "EXIT" / 0 and now call these functions before sig2str() and
  str2sig().

- Bourne Shell: a new version date has been created.

Log message:
shells/pbosh: Specify minimum required version of smake tool dependency

This is required because devel/smake/Makefile.common must be recent enough.

Log message:
shells/pbosh: Update to 20200812

New features with AN-2020-07-18:
- Bourne Shell: A new symlink from /opt/schily/xpg4/bin/bosh to
  /opt/schily/xpg4/bin/sh is created when "smake install" is called.
  This helps people to call "bosh" in strict POSIX mode using the
  command line name "bosh" by putting /opt/schily/xpg4/bin in PATH
  before /opt/schily/bin, where the bosh implements better backwards
  cmpatibility to the Bourne Shell by default than a strictly POSIX
  compliant bosh would do. /opt/schily/xpg4/bin/bosh behaves the same
  as "/opt/schily/bin/bosh -o posix".

  Thanks to  Koichi Nakashima for reporting.

New features with AN-2020-08-12:
- autoconf: added a new test for the existence of <sys/auxv.h>

- autoconf: added new tests for Linux getauxval() and FreeBSD elf_aux_info()

- libschily: getexecpath.c now uses getauxval() on Linux and elf_aux_info()
  on FreeBSD. This was needed since readlink("/proc/curproc/file") on
  FreeBSD returns random values for hardlinked files, making it impossible
  to use the result in order to find out which behavior variant of a
  fat binary is requested.

- Bourne Shell: Several #ifdef SIG* have been added to make it compile
  on older UNIX versions.

  Thanks to a hint from Albert Wik.

Log message:
shells/pbosh: Update to 20200701

Take maintainership.

Changelog from AN-2020-07-01:
- Bourne Shell: A command like

      bosh -c 'var=$({ echo value >&3; } 3>&1); echo $var'

  Did not print "value" as expected, but rather bosh: 3: bad file number

  This is related to the fact that curly brackets do not have an
  own binary node type in the parsed output and the recursive parser
  from the $(cmd) execution needs to reconstruct the text form
  of a command tree. As a result, the command has been translated
  into:

      bosh -c 'var=$( echo value >&3 3>&1); echo $var'

  and this caused the observed problem.

  Note that this basic problem may not be finally fixed, so please
  report in case that other commands with curly brackets together
  with $(cmd) cause problems.

  Thanks to Koichi Nakashima for reporting.

Log message:
shells/pbosh: Update to 2020-05-25

- Use OS specific helper code from devel/smake/Makefile.common

Changes from AN-2020-05-25:
-       libmdgest: Added a "defined(_M_ARM)" check for MSVC byte order
        definitions (byte_order.h).

        Thanks to "Excalibur" for reporting.

-       Bourne Shell: The support for the OLDPWD environment has been moved
        from DO_SYSPUSHD to DO_POSIX_CD and as a result, the minimal POSIX
        compile variant "pbosh" now supports "$OLDPWD" and \ 
"cd -".

        This was based on a bug in the POSIX standard that did not include
        OLDPWD in the overview of shell environment variables. See
        https://www.austingroupbugs.net/view.php?id=1343

        Thanks to Koichi Nakashima for reporting

Log message:
*: Convert broken sourceforge HOMEPAGEs back to http