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.

Kusalananda
  • 333,661
  • 1
    Huh. It works from an interactive shell session, but not a #!ksh93 script. – thrig Mar 01 '17 at 00:00
  • Hint: The question is not quoting the ksh93 manual when it quotes an explanation of the -p option. – JdeBP Mar 01 '17 at 00: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 'SO- stop being evil' Mar 01 '17 at 00:17
  • "Reasonably close" is not "the same". Another hint: This is not the manual's only mention of default paths. – JdeBP Mar 01 '17 at 04:31
  • @JdeBP You are absolutely right, the "default path" is /bin:/usr/bin: according to the ksh93 manual. Any more hints? – Kusalananda Mar 01 '17 at 07:40
  • I see in my ksh man page (93u+) this: "The default path is equal to getconf PATH output", so what is the output of getconf PATH command? – glenn jackman Mar 01 '17 at 16:49
  • @glennjackman I can't find that in my manual, but it is the same path as displayed by my test script in the question, /usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin. My manual says "The default path is /bin:/usr/bin:", but it doesn't matter since /bin is in both paths. – Kusalananda Mar 01 '17 at 16:54

2 Answers2

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.

0

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.