On 17.12.2021 04:38, Martijn Dekker wrote:

Announcing: KornShell 93u+m 1.0.0-beta.2
https://github.com/ksh93/ksh

Great, thanks!

I'll have a look into the details soon, but this one irritated me;
but maybe I just misunderstood it:

- The 'return' command, when used to return from a function, can now
return any status value in the 32-bit signed integer range, like on
zsh. However, due to a traditional Unix kernel limitation, $? is
still trimmed to its least significant 8 bits whenever leaving a
(sub)shell environment.

If in Kornshell I terminate a process with a signal I get a number
returned that is beyond the 8 bit range; e.g. a kill (with SIGTERM)
results in $? evaluating to 271.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 17-12-21 om 09:43 schreef Janis Papanagnou:

I'll have a look into the details soon, but this one irritated me;
but maybe I just misunderstood it:

- The 'return' command, when used to return from a function, can now
return any status value in the 32-bit signed integer range, like on
zsh. However, due to a traditional Unix kernel limitation, $? is
still trimmed to its least significant 8 bits whenever leaving a
(sub)shell environment.

If in Kornshell I terminate a process with a signal I get a number
returned that is beyond the 8 bit range; e.g. a kill (with SIGTERM)
results in $? evaluating to 271.

Yes, that has not changed.

If a child process of ksh's is terminated by a signal, ksh doesn't
inherit the exit status via the kernel as that process didn't exit
normally. Instead, ksh detects that the process was terminated by a
signal (see 'man 2 wait' for how that works) and sets $? to the signal
number with the 9th bit set in the current process -- which is not
subject to the kernel's 8-bit exit status limitation as that all happens
in the parent process.

What the announcement item above means instead is this:

$ myfunc() { return 12345; }
$ myfunc; echo $?
12345
$ (myfunc); echo $?
57
$ ksh -c 'myfunc() { return 12345; }; myfunc'; echo $?
57

i.e., the exit status of a subshell or child shell that invokes
'myfunc', and does nothing to overwrite $? before exiting, is the least significant 8 bits of 12345, i.e., 12345 % 0xFF == 210.

For consistency's sake, ksh 93u+m enforces this for virtual
(non-forking) subshells as well, because a script should never be able
to notice a difference between a virtual subshell and a subshell that
forked a separate process due to executing something like 'ulimit'.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 17 Dec 2021 11:18:26 +0100
Martijn Dekker <martijn@inlv.demon.nl> wrote:

What the announcement item above means instead is this:

$ myfunc() { return 12345; }
$ myfunc; echo $?
12345
$ (myfunc); echo $?
57
$ ksh -c 'myfunc() { return 12345; }; myfunc'; echo $?
57

i.e., the exit status of a subshell or child shell that invokes
'myfunc', and does nothing to overwrite $? before exiting, is the least significant 8 bits of 12345, i.e., 12345 % 0xFF == 210.

For the least significant 8 bits of 12345 the calculation you want is
12345 % 256 == 57 .Regardless , 12345 % 0xFF == 105 .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 17-12-21 om 12:50 schreef Spiros Bousbouras:

On Fri, 17 Dec 2021 11:18:26 +0100
Martijn Dekker <martijn@inlv.demon.nl> wrote:

What the announcement item above means instead is this:

$ myfunc() { return 12345; }
$ myfunc; echo $?
12345
$ (myfunc); echo $?
57
$ ksh -c 'myfunc() { return 12345; }; myfunc'; echo $?
57

i.e., the exit status of a subshell or child shell that invokes
'myfunc', and does nothing to overwrite $? before exiting, is the least
significant 8 bits of 12345, i.e., 12345 % 0xFF == 210.

For the least significant 8 bits of 12345 the calculation you want is
12345 % 256 == 57 .Regardless , 12345 % 0xFF == 105 .

Indeed. Sorry. I was travelling and insufficiently caffeinated while
writing that. What I *meant* was: 12345 & 0xFF == 57


--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17.12.2021 04:38, Martijn Dekker wrote:

Announcing: KornShell 93u+m 1.0.0-beta.2
https://github.com/ksh93/ksh
[...]
Please download the source code tarball from our GitHub releases page:

https://github.com/ksh93/ksh/releases

To build, follow the instructions in README.md or src/cmd/ksh93/README.

I tried a build of the shell, and after a long seamless running compile
got an error. (I seem to recall that I detected it already in a previous release.)

Note: in the logs below I replaced the actual top level directory by ~ .

+ ~/ksh/arch/linux.i386-64/bin/ar x -lsum sumlib.o
/usr/bin/ar: two different operation options specified
mamake [lib/libcmd]: *** exit code 1 making sumlib.o
mamake: *** exit code 1 making lib/libcmd
mamake: *** exit code 1 making all

Got the usage info from the packaged ar (no idea where the -U thing
comes from, and why a different path for ar is displayed)

~/ksh/arch/linux.i386-64/bin/ar --help
/usr/bin/ar: invalid option -- 'U'
Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
/usr/bin/ar -M [<mri-script]

but it seems the call, instead of
ar x -lsum sumlib.o
should probably rather be something like
ar xl sum sumlib.o

An individual call reproduces the error

~/ksh/arch/linux.i386-64/bin/ar x -lsum sumlib.o
/usr/bin/ar: two different operation options specified

while changing the separately started call just complains about the file

~/ksh/arch/linux.i386-64/bin/ar xl sum sumlib.o
/usr/bin/ar: sum: No such file or directory

(which is understandable, since I wasn't executing the test call from
within the build system, probably being in a wrong path or environment variables may be unset).

Is there any fix for that?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 18-12-21 om 14:07 schreef Janis Papanagnou:

On 17.12.2021 04:38, Martijn Dekker wrote:

Announcing: KornShell 93u+m 1.0.0-beta.2
https://github.com/ksh93/ksh
[...]
Please download the source code tarball from our GitHub releases page:

https://github.com/ksh93/ksh/releases

To build, follow the instructions in README.md or src/cmd/ksh93/README.

I tried a build of the shell, and after a long seamless running compile
got an error. (I seem to recall that I detected it already in a previous release.)

Sorry, I'd forgotten about that.

Note: in the logs below I replaced the actual top level directory by ~ .

+ ~/ksh/arch/linux.i386-64/bin/ar x -lsum sumlib.o
/usr/bin/ar: two different operation options specified
mamake [lib/libcmd]: *** exit code 1 making sumlib.o
mamake: *** exit code 1 making lib/libcmd
mamake: *** exit code 1 making all

Got the usage info from the packaged ar (no idea where the -U thing
comes from, and why a different path for ar is displayed)

~/ksh/arch/linux.i386-64/bin/ar --help
/usr/bin/ar: invalid option -- 'U'
Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
/usr/bin/ar -M [<mri-script]

[...]

The cause is probably this ar wrapper script:

$ cat src/cmd/INIT/ar.linux.i386-64

: linux.i386-64 ar wrapper

case $1 in
*x*) /usr/bin/ar "$@" ;;
*) /usr/bin/ar U"$@" ;;
esac

This gets copied into your package hierarchy as
arch/linux.i386-64/bin/ar and put in $PATH.

If you delete the wrapper script in both places

$ rm src/cmd/INIT/ar.linux.i386-64 arch/linux.i386-64/bin/ar

and then try 'bin/package make' again, does it build?

I have no idea what that U thing is for. The AT&T folks must have had
some reason for adding it.

'man ar' on CentOS x86_64 documents:

A number of modifiers (mod) may immediately follow the p
keyletter, to specify variations on an operation's behavior:
[...]
D Operate in deterministic mode. When adding files and the
archive index use zero for UIDs, GIDs, timestamps, and use
consistent file modes for all files. When this option is
used, if ar is used with identical options and identical
input files, multiple runs will create identical output
files regardless of the input files' owners, groups, file
modes, or modification times.
[...]
U Do not operate in deterministic mode. This is the inverse
of the D modifier, above: added files and the archive index
will get their actual UID, GID, timestamp, and file mode
values.

This is the default unless binutils was configured with
--enable-deterministic-archives.

So the question is, why would we want to disable deterministic mode? It
sounds like a good thing.

If you can confirm that deleting the wrapper script fixes your build
failure, I'll get rid of it and see if anything breaks for anyone else.

(In fact in the long term I plan to get rid of all such wrapper scripts.
It's a very flawed way of making a build work. Just overriding the
default compiler or linker using the appropriate failures will disable
the wrappers so the necessary flags aren't added. There are better ways
of doing this.)

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 19-12-21 om 21:00 schreef Martijn Dekker:

If you can confirm that deleting the wrapper script fixes your build
failure, I'll get rid of it and see if anything breaks for anyone else.

In the meantime I got rid of that wrapper script and some others on the
1.0 branch: https://github.com/ksh93/ksh/commit/24fc1bbc

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.12.2021 22:00, Martijn Dekker wrote:

[...]
If you delete the wrapper script in both places

$ rm src/cmd/INIT/ar.linux.i386-64 arch/linux.i386-64/bin/ar

and then try 'bin/package make' again, does it build?

I'll try this and also your github changes after the holidays.

Thank you!

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)