For the BSD's we do not want to pass CFLAGS since it includes a
-I/usr/local/incude directive.
This breaks ksh's iconv detection due to the weird way in which iconv
seems to be handled on the BSD's - both a libc impl (preferred), and a
possibly external GNU iconv impl installed in /usr/local.
/usr/local/include is added to CFLAGS by the X11/Motif detection logic
- since that is where all of the needed headers are on the BSDs.
One of the patches from Martijn Decker added CFLAGS to the ksh93 build
CCFLAGS which made this problem show up.
So until/unless that is fixed in ksh93, we will avoid sending
anything to the ksh build system except for SUIDEXECDEFINES
Patch from current ksh93 maintainer <https://github.com/ksh93/ksh>.
cde/programs/dtksh/ksh93/**:
- Upgraded. A load of bugs fixed, some minor features added.
See NEWS from 2021-02-01 upwards.
cde/programs/dtksh/Makefile.am:
- Don't cd into ksh93 any more to invoke the package or shtests
scripts; they now automatically find their directories.
- Pass $(CFLAGS) to build ksh with optimisation.
- Remove -D_std_malloc flag as vmalloc is now deprecated and disabled
by default.
- Add a 'make check' target to Makefile.am that runs the ksh93
regression tests on dtksh to make sure the additions don't interfere
with anything. It skips running the tests with shcomp because CDE
doesn't use that. The tests all pass here on Slackware 14.2. :-)
cde/programs/dtksh/init.patch:
- Removed; I've upstreamed it. It was the only one that wasn't upstreamed
yet, and more code cleanups are coming, breaking downstream patches. If
something needs updating, just email me a diff.
cde/programs/dtksh/dtkcmds.h:
- Update the ADDBUILTIN macro to remove the __PROTO__ macro use. The
proto(1) tool, responsible for all such pre-C89 K&R C compatibility
voodoo, has been removed, so that macro is no longer defined.
cde/programs/dtksh/setup.sh:
- Workaround script removed. I rewrote 'bin/package flat make' in a way
that works correctly and changed Makefile.am to use that instead.
Hope this helps. Happy new year.
Shell isn't portable, so upstream ksh93 has a "flat" function that we can use
to put binaries in a static place that doesn't require a shell command. We still
do need an intermediate setup.sh shell script due to a bug in ksh that object
files aren't being put in lib, and FEATURE not in include. We also cut out some
unused symbols, and a hpux specific implementation of dynlib (new hpux should
conform to the posix implementation anyhow.)
We can reduce our differences from upstream ksh by simply using their
ERROR_translate() function instead of our janky and obsolete msg_translate,
we also move DtGetMessage() to msgs.c and lockedfiledescriptors and,
unlockfiledescriptors to extra.c to lessen modifications to init.c, which
all changes will hopefully be moved elsewhere in the future
This commit does three thing:
1. Sets appropriate bits on source files
2. Tells imake to build them as script files, not data files
3. Remove broken examples based on unused code
Upstream ksh has removed it's builtin aliases, favoring instead to make them
all builtin commands, this would also allow us to skip having to manually
merge another file, it was explained best in this email:
"Default aliases are an ugly hack that you are better off without.
Disadvantages include:
- 'unalias -a' becomes basically unusable as it gets rid of commands you
probably want;
- shell functions by those names are ignored (unless you quote their
names upon invocation);
- something like 'cmdname=foo; "$cmdname" bar baz' doesn't work if
$cmdname is an alias.
I strongly recommend removing the BLT_SPC flag from all of
your extra dtksh builtins. Making builtins "special builtins" is of no
real benefit at all, while introducing a pointless restriction: shell
functions by those names cannot be defined, which causes a risk of
incompatibility with scripts written for other shells. The BLT_SPC flag
is for a very few historic builtins that must have certain weird
corner-case behaviour of "special" builtins for POSIX compliance and
Bourne shell compatibility reasons."
Some of these functions were returning pointers cast as integers,
which of course is bad on a 64b LP64 systems.
This code should probably just be refactored at some point. There may
be other hidden issues, and all the casting just sucks.
Chase