2

I have an issue with using command -p mkdir in a ksh93 shell script.

The command -p bit is supposed to, according to POSIX,

Perform the command search using a default value for PATH that is guaranteed to find all of the standard utilities.

The ksh93 manual has a similar wording:

The -p option causes a default path to be searched rather than the one defined by the value of PATH. Functions will not be searched for when finding name. In addition, if name refers to a special built-in, none of the special properties associated with the leading daggers will be honored. (For example, the predefined alias redirect='command exec' prevents a script from terminating when an invalid redirection is given.)

I've boiled my script down to the following:

#!/usr/local/bin/ksh93 -x
echo "$PATH"
command -p mkdir t

Running it:

$ ./test.sh
+ echo /usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
+ command -p mkdir t
./test.sh[3]: mkdir: not found [No such file or directory]

The default value of $PATH for ksh93 (according to its manual) is /bin:/usr/bin:, and mkdir is found in /bin:

$ command -v mkdir
/bin/mkdir

If I issue the getconf PATH command in the script (to get the value of the default system-defined $PATH), before calling mkdir, the call to mkdir succeeds.

This is seen in ksh93, "Version AJM 93u+ 2012-08-01", on at least Ubuntu, OpenBSD, macOS and Solaris, and also affect at least cat when invoked the same way.

The question: Did I miss something obvious here?

Additional info:

The builtin command in ksh93 lists a number of utilities under the (non-existent) path /opt/ast/bin. Does this have something to do with this?

$ builtin
:
.
[
/opt/ast/bin/basename
/opt/ast/bin/cat
/opt/ast/bin/chmod
/opt/ast/bin/cmp
/opt/ast/bin/cut
/opt/ast/bin/dirname
/opt/ast/bin/getconf
/opt/ast/bin/head
/opt/ast/bin/logname
/opt/ast/bin/mkdir
/opt/ast/bin/sync
/opt/ast/bin/uname
/opt/ast/bin/wc
alarm
alias

(etc.)

UPDATE: I have submitted this query to the ast-users mailing list as well.

  • 1
    Huh. It works from an interactive shell session, but not a #!ksh93 script. – thrig Mar 1 '17 at 0:00
  • Hint: The question is not quoting the ksh93 manual when it quotes an explanation of the -p option. – JdeBP Mar 1 '17 at 0:12
  • @JdeBP So? The ksh93 manual states “The -p option causes a default path to be searched rather than the one defined by the value of PATH”, which is reasonably close. And ksh93 does strive to be POSIX-compliant. This smells like a bug. – Gilles Mar 1 '17 at 0:17
  • "Reasonably close" is not "the same". Another hint: This is not the manual's only mention of default paths. – JdeBP Mar 1 '17 at 4:31
  • @JdeBP You are absolutely right, the "default path" is /bin:/usr/bin: according to the ksh93 manual. Any more hints? – Kusalananda Mar 1 '17 at 7:40
2

Based on what you've shown here and on ast-user, this looks like a bug, but this is not an answer to that question.

Re Builtin

This might better be answered in a separate question, but for now this must suffice:

Ksh93 has a feature where additional commands can be loaded from shared libraries, and then bound to an existing (or non-existing) directory in $PATH

The commands with the /opt/ast/bin/ path are considered to be bound to /opt/ast/bin. That means that if a $PATH has /opt/bin/ast/bin before /bin, ksh93 will invoke the builtin cat in preference over /bin/cat.

Whether /opt/ast/bin or /opt/ast/bin/cat exist or not does not have any effect on this mechanism.

  • Ah, that explains the mysterious paths. Thanks! – Kusalananda Mar 1 '17 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.