Added -p and -l options to umask, builtin and trap built-ins

[JohnoKing]

This pull request adds the following options for printing reinputtable command output:
umask -p (ksh93v- backport)
builtin -p (ksh93v- backport)
hash -l

Additionally, trap -l has been backported from ksh93v- for listing signals.

[McDutchie]

Did you have any use case in mind for hash -l? Since tracked aliases are considered obsolete anyway, and they don't really affect command execution at all (any invalid entry will be ignored), I'm not really seeing it.

[McDutchie]

An oddity:

$ builtin -p what is this
builtin what
builtin is
builtin this

I think the builtin -p option should either error out if there are any arguments, or verify that each argument represents a currently active builtin and print it with its virtual path, if any. For instance, I think builtin -p basename should either error out or print builtin /opt/ast/bin/basename (in the default configuration).

[JohnoKing]

I've fixed builtin -p to error out if the provided builtins don't exist. Regarding /opt/ast/bin builtins, it will not register the builtin's existence unless it's first loaded or if it's accessed by the direct virtual path:

$ builtin -p cat
builtin: cat: not found
$ builtin cat
$ builtin -p cat
builtin cat
$ builtin -p /opt/ast/bin/cut cut
builtin /opt/ast/bin/cut
builtin: cut: not found
$ builtin cut
$ builtin -p /opt/ast/bin/cut cut
builtin /opt/ast/bin/cut
builtin cut

Did you have any use case in mind for hash -l?

Not particularly. The main reason I added it was because bash has it, and because the feature was cheap to implement as far as LOC goes.

Edit 06-09-2025: I'l also note that the -l option gives the hash builtin feature parity with tracked alias listing obtainable via the already implemented alias -pt. (The main difference is that hash -l, being provided by bash, is not a kshism, whereas alias -pt certainly is one. hash -l is of course a bashism, but compatibility isn't necessarily a bad thing, especially given that hash -l is little more than a scant few lines of C.)

[McDutchie]

Not particularly. The main reason I added it was because bash has it, and because the feature was cheap to implement as far as LOC goes.

Edit 06-09-2025: I'l also note that the -l option gives the hash builtin feature parity with tracked alias listing obtainable via the already implemented alias -pt.

I've fixed builtin -p to error out if the provided builtins don't exist. Regarding /opt/ast/bin builtins, it will not register the builtin's existence unless it's first loaded or if it's accessed by the direct virtual path:

$ builtin -p cat
builtin: cat: not found
$ builtin cat
$ builtin -p cat
builtin cat
$ builtin -p /opt/ast/bin/cut cut
builtin /opt/ast/bin/cut
builtin: cut: not found
$ builtin cut
$ builtin -p /opt/ast/bin/cut cut
builtin /opt/ast/bin/cut
builtin cut

Did you have any use case in mind for hash -l?

Not particularly. The main reason I added it was because bash has it, and because the feature was cheap to implement as far as LOC goes.

Edit 06-09-2025: I'l also note that the -l option gives the hash builtin feature parity with tracked alias listing obtainable via the already implemented alias -pt.

However, the bash feature is different:

$ bash
bash-5.2$ ls >/dev/null
bash-5.2$ hash -l
builtin hash -p /bin/ls ls

So bash produces commands that recreate the tracked aliases as they were, without searching them in PATH again. This is the true meaning of "recreating the current tracked aliases". Your ksh version doesn't do this. Even if it did, it wouldn't make a difference, because unlike bash, ksh effectively ignores the hash table when doing PATH searches.

So I don't think hash -l is useful, and I'd rather have this PR without it.