From C, what's the easiest way to run a standard utility (e.g., ps) and no other?

Does POSIX guarantee that, for example, a standard ps is in /bin/ps or should I reset the PATH environment variable to what I get with confstr(_CS_PATH, pathbuf, n); and then run the utility through PATH-search?

  • 1
    I have in the back of my head that POSIX says, for a number of commands, among them ed(1) (which is important for mksh), that, if they are available, they also must be reachable under /bin, i.e. /bin/ed must be usable if ed is installed. I can’t find it right now, but I know LSB depends on it, and I’ve successfully defended bugreports using that as rationale, so it must at least have been true at some point. (Or it was something other than POSuX and I misremember, but the rest is true.)
    – mirabilos
    Sep 4, 2019 at 21:28

2 Answers 2


No, it doesn't, mainly for the reason that it doesn't require systems to conform by default, or to comply to only the POSIX standard (to the exclusion of any other standard).

For instance, Solaris (a certified compliant system) chose backward compatibility for its utilities in /bin, which explains why those behave in arcane ways, and provide POSIX-compliant utilities in separate locations (/usr/xpg4/bin, /usr/xpg6/bin... for different versions of the XPG (now merged into POSIX) standard, those being actually part of optional components in Solaris).

Even sh is not guaranteed to be in /bin. On Solaris, /bin/sh used to be the Bourne shell (so not POSIX compliant) until Solaris 10, while it's now ksh93 in Solaris 11 (still not fully POSIX compliant, but in practice more so than /usr/xpg4/bin/sh).

From C, you could use exec*p() and assume you're in a POSIX environment (in particular regarding the PATH environment variable).

You could also set the PATH environment variable

#define _POSIX_C_SOURCE=200809L /* before any #include */
confstr(_CS_PATH, buf, sizeof(buf)); /* maybe append the original
                                      * PATH if need be */
setenv("PATH", buf, 1);

Or you could determine at build time the path of the POSIX utilities you want to run (bearing in mind that on some systems like GNU ones, you need more steps like setting a POSIXLY_CORRECT variable to ensure compliance).

You could also try things like:

execlp("sh", "sh", "-c", "PATH=`getconf PATH`${PATH+:$PATH};export PATH;"
                         "unset IFS;shift \"$1\";"
                         "exec ${1+\"$@\"}", "2", "1", "ps", "-A"...);

In the hope that there's a sh in $PATH, that it is Bourne-like, that there's also a getconf and that it's the one for the version of POSIX you're interested in.

  • So what do you do for #!?
    – Joshua
    Sep 3, 2019 at 20:58
  • 15
    @Joshua: You pray that /usr/bin/env exists and is mostly POSIX-compliant.
    – Kevin
    Sep 3, 2019 at 21:04
  • 3
    @Kevin or you familiarise yourself with the quirks of your palaeo-unix and adjust the #! line to use the correct path.
    – cas
    Sep 4, 2019 at 1:43
  • 5
    @Kevin: No. /usr/bin/env is an even less portable (in practice) hack than /bin/sh. Per POSIX, the portable way to write a shell script is with no #! at all. If a file is executable but ENOEXEC (not a valid binary), execvp is to execute it via the standard shell. :-) Of course in practice this is a bad idea and you should just use #!/bin/sh. Sep 4, 2019 at 13:52
  • 2
    @GeoffNixon, that part you're refering to is an alternative for when you don't, can't or don't want to use _POSIX_C_SOURCE. It does the setting of $PATH from the shell instead of from C. Sep 4, 2019 at 15:04

Actually, I would largely answer yes. POSIX does guarantee:

  1. That there is an absolute path a to standards-compliant version of each specified utility,
  2. And, that you must be able to find this absolute path, and be able to execute this utility.

Though it is not necessarily guaranteed that each utility shall be in a particular directory across all systems (/bin/ps), it always guaranteed to be able to be found in the system default PATH, as an executable file.

Indeed, the only standard-specified way to do this in the standard is (in C) via unistd.h's _CS_PATH, or in the shell, via a combination of command and getconf utilities, i.e., PATH="$(command -p getconf PATH)" command -v ps must always return the unique absolute path of the POSIX-compliant ps supplied on a particular system. That is, while it is implementation-defined which paths are included in the system default PATH variable, these utilites must always be available, unique, and compliant, in one of the paths specified therein.

See: <unistd.h>, command.

  • 1
    But for sh, there's a chicken and egg problem. That PATH=$(command -p getconf PATH) will only work from a POSIX shell in a POSIX environment. POSIX doesn't specify how you get into that environment, just that it be documented. For instance, on Solaris, you have a /usr/xpg4/bin/getconf and a /usr/xpg6/bin/getconf which would return different values for _CS_PATH for the two different versions of the standard and neither /usr/xpg4/bin nor /usr/xpg6/bin are in the default value of $PATH. There is a /usr/bin/getconf which IIRC gives you XPG4 conformance. Sep 4, 2019 at 14:43
  • Is that true for even for Solaris 11+ (UNIX 03+ certified) versions? I've always read ``` Applications... should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. For example, to determine the location of the standard sh utility: command -v sh On some implementations this might return: /usr/xpg4/bin/sh ``` to mean this must be an entry to a POSIX compliant sh from any default shell. Sep 4, 2019 at 15:05
  • 1
    There's nothing in POSIX that says that there should be a getconf command in the default $PATH of a given system. For instance, getting a POSIX environment may involve starting an emulation layer, without which you wouldn't run any Unix-like command at all (think Windows for instance). Once you are in a compliant environment, getconf PATH will get you a $PATH to get to compliant utilities, but if you were in a POSIX environment, that was probably already the case. Note that getconf ps may return ps. Having ps builtin is allowed. Sep 4, 2019 at 15:24
  • @StéphaneChazelas I really don't follow your argument—I mean its logic is sound, but tautologically meaningless. No, POSIX does not guarantee the existence of geconf in a default $PATH of ANY given system. And forget Windows... Mac OS is Certified UNIX, and it requires opening a Terminal [Emulator] for these. But that's not a limition on POSIX. POSIX doesn't guarantee any existence of anything in any other "given system" but within POSIX... life, spacetime, God, MSDOS. It specifies behavior of systems that conform to POSIX. Yes, only once in a compliant environment—but thats no limitation. Oct 6, 2020 at 13:52

You must log in to answer this question.

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