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
+ 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

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


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
    Commented Mar 1, 2017 at 0:00
  • Hint: The question is not quoting the ksh93 manual when it quotes an explanation of the -p option.
    – JdeBP
    Commented Mar 1, 2017 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. Commented Mar 1, 2017 at 0:17
  • "Reasonably close" is not "the same". Another hint: This is not the manual's only mention of default paths.
    – JdeBP
    Commented Mar 1, 2017 at 4:31
  • @JdeBP You are absolutely right, the "default path" is /bin:/usr/bin: according to the ksh93 manual. Any more hints?
    – Kusalananda
    Commented Mar 1, 2017 at 7:40

2 Answers 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
    Commented Mar 1, 2017 at 20:33

command -p is known to be very buggy in AT&T release versions of ksh93 because the default/standard path is not initialised properly. This is one of the many hundreds of bugs fixed in ksh 93u+m which is under active maintenance and development (I'm the main dev/maintainer). It is currently the default ksh93 in at least Debian unstable and Slackware-current, but of course you can also get the code and compile your own.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .