Opened 6 months ago

Last modified 6 months ago

#64181 accepted defect

ksh @2020.0.0_1 : typeset -f crashes the shell

Reported by: posguy99 (Marc Wilson) Owned by: ryandesign (Ryan Schmidt)
Priority: Low Milestone:
Component: ports Version: 2.7.1
Keywords: bigsur Cc:
Port: ksh

Description

It crashes when you attempt to list defined functions. As below:

$ ver
ksh: Version A 2020.0.0
$ typeset -f
### 67416 Function backtrace:
1   handle_sigsegv (in ksh) + 11
2   _sigtramp (in libsystem_platform.dylib) + 29
3   0x2000000020
4   print_scan (in ksh) + 610
5   setall (in ksh) + 3763
6   b_typeset (in ksh) + 2630
7   sh_exec (in ksh) + 15481
8   exfile (in ksh) + 1783
9   sh_main (in ksh) + 1827
10  start (in libdyld.dylib) + 1
Abort

I recognize that according to the port, it may be removed soon, but a crasher would seem to warrant removal sooner, especially since the 2020 fork of ksh is abandoned upstream.

Would like to suggest that MacPorts consider replacing it with ksh93u+m, available here: https://github.com/ksh93/ksh

Change History (8)

comment:1 Changed 6 months ago by ryandesign (Ryan Schmidt)

I don't see that output on my system (neither from ver nor from typeset -f) but I know pretty much nothing about ksh so I'm probably doing it wrong.

Yes, the whole ksh story is pretty sad. I agree there's no point keeping ksh and ksh-devel since that development effort was rejected by the project's owners and abandoned by the developer who contributed it.

We still have the ksh93 port. I suppose it's that port which should be updated to this ksh93u+m you mention? Or is there value in offering both the ksh93 2012-08-01 that we already offer and separately ksh93u+m?

comment:2 Changed 6 months ago by posguy99 (Marc Wilson)

Sorry, I wasn't clear.

$ cat $FPATH/ver
# Shortcut to show current shell version
function ver {
    printf 'ksh: %s\n' "${KSH_VERSION:-unknown}"
}

I was showing there was at least one function there. :) When you tested it, did you have a function definition present?

Regarding replacing ksh93 with ksh93u+m, well, there is probably value in having the ATT codebase there too, but Apple ships ksh93 in base right now. I think it has a different set of patches, though.

comment:3 in reply to:  2 Changed 6 months ago by ryandesign (Ryan Schmidt)

Replying to posguy99:

Sorry, I wasn't clear.

$ cat $FPATH/ver
# Shortcut to show current shell version
function ver {
    printf 'ksh: %s\n' "${KSH_VERSION:-unknown}"
}

I was showing there was at least one function there. :) When you tested it, did you have a function definition present?

Here's what I have:

$ /opt/local/bin/ksh
[033[01;32m]u@h [033[01;36m]W $ [033[00m]cat $FPATH/ver
cat: /ver: No such file or directory
[033[01;32m]u@h [033[01;36m]W $ [033[00m]ver
/opt/local/bin/ksh: ver: not found
[033[01;32m]u@h [033[01;36m]W $ [033[00m]typeset -f
[033[01;32m]u@h [033[01;36m]W $ [033[00m]

I have no idea if I have a function definition present. I guess I have whatever the ksh port provides when it is installed.

Regarding replacing ksh93 with ksh93u+m, well, there is probably value in having the ATT codebase there too, but Apple ships ksh93 in base right now. I think it has a different set of patches, though.

What Apple does or doesn't ship in macOS isn't of particular relevance when deciding what we should have in MacPorts. Apple has a habit of either not updating their bundled open source software for years and years (like bash for instance. though of course there is a (GPL-3) reason for that) or of removing it entirely at some point (like php as of macOS 12). So just because Apple ships it in macOS doesn't mean we shouldn't have it in MacPorts.

The problem with our ksh93 port is that it does not build on OS X 10.9 or later, which makes it pretty useless. That was part of the motivation for switching to the now-aborted 2020 branch. If the new ksh93u+m builds on newer systems, that would again be motivation for switching that port to the new fork.

Per the new fork's description, the old att ast repository

is no longer under active development

and

we are confident at this point that 93u+m is already the least buggy branch of ksh93 ever released

Those seem like good reasons to switch to it and leave the old original unbuildable ksh93 behind.

If there are really users of OS X 10.8 and earlier who would prefer to keep using the original ksh93 rather than the new ksh93u+m, I guess we could make a separate ksh93um port, but I would kind of rather not.

I see that Debian unstable is making this available as "ksh93u+m". The "+" character is not allowed in MacPorts port names though.

comment:4 Changed 6 months ago by posguy99 (Marc Wilson)

I have ver in my FPATH. The ksh port doesn't include it, so I gave the definition for it. If you put that in a file, and then execute it, it will be added as a function. Might be interesting to add it as a function, then see if yours crashes like mine did. I have more than a few things in FPATH, and have several dicipline functions in kshrc as well, so who really knows what's making typeset crash.

I'd never tried to install MacPorts ksh93, I didn't realize that it didn't build or wasn't even installable ( I don't have a macOS < 12). Since it is 93u+20120801, I already had it. :)

The ksh93u+m certainly does build on a current macOS, I'm using it now as a daily driver on both 10.15 and 11.6.

Slackware is also tracking ksh93u+m as ksh, if it matters.

comment:5 Changed 6 months ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… removed
Owner: set to ryandesign
Status: newaccepted

Here's what I see:

$ /opt/local/bin/ksh
[033[01;32m]u@h [033[01;36m]W $ [033[00m]function ver {
>     printf 'ksh: %s\n' "${KSH_VERSION:-unknown}"
> }
[033[01;32m]u@h [033[01;36m]W $ [033[00m]ver
ksh: Version A 2020.0.0
[033[01;32m]u@h [033[01;36m]W $ [033[00m]typeset -f
function ver {
    printf 'ksh: %s\n' "${KSH_VERSION:-unknown}"
}
[033[01;32m]u@h [033[01;36m]W $ [033[00m]

So, no crash at typeset -f for me on Catalina, but I don't need to reproduce your crash; I already agree the ksh and ksh-devel ports should go away. I'll update ksh93 to the new fork you mention and add a ksh93-devel to track its development between releases, and mark ksh and ksh-devel replaced by the new ones.

comment:6 Changed 6 months ago by ryandesign (Ryan Schmidt)

On second thought, I'll leave ksh93 alone for now and add a ksh93-devel for the new fork since it is not stable yet, and probably replace ksh93 with it once it releases a stable version.

However, at this time, both that fork's 1.0.0-beta.1 release and the latest commit as of yesterday fail to build for me in the same way that the ksh93 port currently fails to build. See #43392. I filed https://github.com/ksh93/ksh/issues/373 for this.

comment:7 Changed 6 months ago by posguy99 (Marc Wilson)

I see that you and @McDutchie solved it.

comment:8 Changed 6 months ago by ryandesign (Ryan Schmidt)

In 1567a64bf5a0797bd19c6ee53b157089471221cb/macports-ports (master):

ksh93-devel: New port, version 93u+m-1.0.0-beta.1

See: #64181

Note: See TracTickets for help on using tickets.