1COMMAND(1P)                POSIX Programmer's Manual               COMMAND(1P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10
11

NAME

13       command — execute a simple command
14

SYNOPSIS

16       command [−p] command_name [argument...]
17
18       command [−p][−v|−V] command_name
19

DESCRIPTION

21       The command utility shall cause the shell to treat the arguments  as  a
22       simple command, suppressing the shell function lookup that is described
23       in Section 2.9.1.1, Command Search and Execution, item 1b.
24
25       If the command_name is the same as the  name  of  one  of  the  special
26       built-in  utilities,  the  special properties in the enumerated list at
27       the beginning of Section 2.14, Special  Built-In  Utilities  shall  not
28       occur.  In  every  other  respect, if command_name is not the name of a
29       function, the effect of command (with no options) shall be the same  as
30       omitting command.
31
32       When  the  −v  or  −V option is used, the command utility shall provide
33       information concerning how a command name is interpreted by the shell.
34

OPTIONS

36       The command utility shall conform to the  Base  Definitions  volume  of
37       POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines.
38
39       The following options shall be supported:
40
41       −p        Perform  the  command  search  using a default value for PATH
42                 that is guaranteed to find all of the standard utilities.
43
44       −v        Write a string to standard output that indicates the pathname
45                 or  command  that  will  be used by the shell, in the current
46                 shell execution environment (see Section 2.12,  Shell  Execu‐
47                 tion  Environment), to invoke command_name, but do not invoke
48                 command_name.
49
50                  *  Utilities,  regular  built-in  utilities,   command_names
51                     including  a  <slash>  character, and any implementation-
52                     defined functions that are found using the PATH  variable
53                     (as described in Section 2.9.1.1, Command Search and Exe‐
54                     cution), shall be written as absolute pathnames.
55
56                  *  Shell  functions,  special  built-in  utilities,  regular
57                     built-in utilities not associated with a PATH search, and
58                     shell reserved words  shall  be  written  as  just  their
59                     names.
60
61                  *  An  alias  shall be written as a command line that repre‐
62                     sents its alias definition.
63
64                  *  Otherwise, no output shall be written and the exit status
65                     shall reflect that the name was not found.
66
67       −V        Write a string to standard output that indicates how the name
68                 given in the command_name operand will be interpreted by  the
69                 shell,  in  the current shell execution environment (see Sec‐
70                 tion 2.12, Shell Execution Environment), but  do  not  invoke
71                 command_name.  Although the format of this string is unspeci‐
72                 fied, it shall indicate in which of the following  categories
73                 command_name falls and shall include the information stated:
74
75                  *  Utilities,  regular built-in utilities, and any implemen‐
76                     tation-defined functions that are found  using  the  PATH
77                     variable (as described in Section 2.9.1.1, Command Search
78                     and Execution), shall be identified as such  and  include
79                     the absolute pathname in the string.
80
81                  *  Other shell functions shall be identified as functions.
82
83                  *  Aliases  shall be identified as aliases and their defini‐
84                     tions included in the string.
85
86                  *  Special built-in utilities shall be identified as special
87                     built-in utilities.
88
89                  *  Regular  built-in  utilities  not  associated with a PATH
90                     search shall be identified as regular built-in utilities.
91                     (The term ``regular'' need not be used.)
92
93                  *  Shell  reserved  words  shall  be  identified as reserved
94                     words.
95

OPERANDS

97       The following operands shall be supported:
98
99       argument  One of the strings treated as an argument to command_name.
100
101       command_name
102                 The name of a utility or a special built-in utility.
103

STDIN

105       Not used.
106

INPUT FILES

108       None.
109

ENVIRONMENT VARIABLES

111       The following environment variables shall affect the execution of  com‐
112       mand:
113
114       LANG      Provide  a  default  value for the internationalization vari‐
115                 ables that are unset or null. (See the Base Definitions  vol‐
116                 ume  of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
117                 ables for the precedence  of  internationalization  variables
118                 used to determine the values of locale categories.)
119
120       LC_ALL    If  set  to  a non-empty string value, override the values of
121                 all the other internationalization variables.
122
123       LC_CTYPE  Determine the locale for the interpretation of  sequences  of
124                 bytes of text data as characters (for example, single-byte as
125                 opposed to multi-byte characters in arguments).
126
127       LC_MESSAGES
128                 Determine the locale that should be used to affect the format
129                 and contents of diagnostic messages written to standard error
130                 and informative messages written to standard output.
131
132       NLSPATH   Determine the location of message catalogs for the processing
133                 of LC_MESSAGES.
134
135       PATH      Determine  the  search  path  used  during the command search
136                 described in Section 2.9.1.1, Command Search  and  Execution,
137                 except as described under the −p option.
138

ASYNCHRONOUS EVENTS

140       Default.
141

STDOUT

143       When the −v option is specified, standard output shall be formatted as:
144
145           "%s\n", <pathname or command>
146
147       When the −V option is specified, standard output shall be formatted as:
148
149           "%s\n", <unspecified>
150

STDERR

152       The standard error shall be used only for diagnostic messages.
153

OUTPUT FILES

155       None.
156

EXTENDED DESCRIPTION

158       None.
159

EXIT STATUS

161       When  the  −v  or  −V  options are specified, the following exit values
162       shall be returned:
163
164        0    Successful completion.
165
166       >0    The command_name could not be found or an error occurred.
167
168       Otherwise, the following exit values shall be returned:
169
170       126   The utility specified by command_name was found but could not  be
171             invoked.
172
173       127   An error occurred in the command utility or the utility specified
174             by command_name could not be found.
175
176       Otherwise, the exit status of command shall be that of the simple  com‐
177       mand specified by the arguments to command.
178

CONSEQUENCES OF ERRORS

180       Default.
181
182       The following sections are informative.
183

APPLICATION USAGE

185       The  order  for  command  search  allows  functions to override regular
186       built-ins and path searches. This utility is necessary to  allow  func‐
187       tions that have the same name as a utility to call the utility (instead
188       of a recursive call to the function).
189
190       The system default path is available using getconf; however, since get‐
191       conf  may  need to have the PATH set up before it can be called itself,
192       the following can be used:
193
194           command −p getconf PATH
195
196       There are some advantages to suppressing the special characteristics of
197       special built-ins on occasion. For example:
198
199           command exec > unwritable-file
200
201       does  not  cause  a non-interactive script to abort, so that the output
202       status can be checked by the script.
203
204       The command, env, nohup, time, and xargs utilities have been  specified
205       to  use  exit code 127 if an error occurs so that applications can dis‐
206       tinguish ``failure to find a utility'' from  ``invoked  utility  exited
207       with  an error indication''. The value 127 was chosen because it is not
208       commonly used for other meanings; most utilities use small  values  for
209       ``normal  error  conditions''  and the values above 128 can be confused
210       with termination due to receipt of a signal. The value 126  was  chosen
211       in  a  similar  manner to indicate that the utility could be found, but
212       not invoked. Some scripts produce meaningful error messages differenti‐
213       ating the 126 and 127 cases. The distinction between exit codes 126 and
214       127 is based on KornShell practice that uses 127 when all  attempts  to
215       exec  the  utility fail with [ENOENT], and uses 126 when any attempt to
216       exec the utility fails for any other reason.
217
218       Since the −v and −V options of command produce output  in  relation  to
219       the  current shell execution environment, command is generally provided
220       as a shell regular built-in. If it is called in a subshell or  separate
221       utility execution environment, such as one of the following:
222
223           (PATH=foo command −v)
224            nohup command −v
225
226       it  does  not  necessarily  produce  correct results. For example, when
227       called with nohup or an exec function, in a separate utility  execution
228       environment,  most  implementations  are  not able to identify aliases,
229       functions, or special built-ins.
230
231       Two types of regular built-ins could be encountered  on  a  system  and
232       these  are described separately by command.  The description of command
233       search in Section 2.9.1.1, Command Search and Execution  allows  for  a
234       standard  utility to be implemented as a regular built-in as long as it
235       is found in the appropriate place in a PATH search.  So,  for  example,
236       command  −v  true might yield /bin/true or some similar pathname. Other
237       implementation-defined utilities that are not defined by this volume of
238       POSIX.1‐2008 might exist only as built-ins and have no pathname associ‐
239       ated with them. These produce output identified as (regular) built-ins.
240       Applications  encountering these are not able to count on execing them,
241       using them with nohup, overriding them with a different  PATH,  and  so
242       on.
243

EXAMPLES

245        1. Make  a version of cd that always prints out the new working direc‐
246           tory exactly once:
247
248               cd() {
249                   command cd "$@" >/dev/null
250                   pwd
251               }
252
253        2. Start off a ``secure shell script''  in  which  the  script  avoids
254           being spoofed by its parent:
255
256               IFS='
257               '
258               #    The preceding value should be <space><tab><newline>.
259               #    Set IFS to its default value.
260
261               \unalias −a
262               #    Unset all possible aliases.
263               #    Note that unalias is escaped to prevent an alias
264               #    being used for unalias.
265
266               unset −f command
267               #    Ensure command is not a user function.
268
269               PATH="$(command −p getconf PATH):$PATH"
270               #    Put on a reliable PATH prefix.
271
272               #    ...
273
274           At  this point, given correct permissions on the directories called
275           by PATH, the script has the ability to ensure that any  utility  it
276           calls  is  the  intended  one. It is being very cautious because it
277           assumes that implementation extensions may be  present  that  would
278           allow  user  functions to exist when it is invoked; this capability
279           is not specified by this volume of POSIX.1‐2008, but it is not pro‐
280           hibited as an extension. For example, the ENV variable precedes the
281           invocation of the script with a user start-up script. Such a script
282           could define functions to spoof the application.
283

RATIONALE

285       Since command is a regular built-in utility it is always found prior to
286       the PATH search.
287
288       There is nothing in the description of command that implies the command
289       line  is  parsed any differently from that of any other simple command.
290       For example:
291
292           command a | b ; c
293
294       is not parsed in any special way that causes '|' or ';' to  be  treated
295       other  than  a  pipe  operator or <semicolon> or that prevents function
296       lookup on b or c.
297
298       The command utility is somewhat similar to  the  Eighth  Edition  shell
299       builtin  command,  but  since  command  also goes to the file system to
300       search for utilities, the name builtin would not be intuitive.
301
302       The command utility is most likely to be provided as a  regular  built-
303       in. It is not listed as a special built-in for the following reasons:
304
305        *  The  removal of exportable functions made the special precedence of
306           a special built-in unnecessary.
307
308        *  A special built-in has special properties (see Section  2.14,  Spe‐
309           cial Built-In Utilities) that were inappropriate for invoking other
310           utilities. For example, two commands such as:
311
312               date > unwritable-file
313
314               command date > unwritable-file
315
316           would have entirely different results; in a non-interactive script,
317           the  former  would continue to execute the next command, the latter
318           would abort. Introducing this semantic difference along  with  sup‐
319           pressing functions was seen to be non-intuitive.
320
321       The  −p  option  is present because it is useful to be able to ensure a
322       safe path search that finds all the  standard  utilities.  This  search
323       might  not  be identical to the one that occurs through one of the exec
324       functions (as defined in the System Interfaces volume of  POSIX.1‐2008)
325       when  PATH  is  unset.  At  the very least, this feature is required to
326       allow the script to access the correct version of getconf so  that  the
327       value of the default path can be accurately retrieved.
328
329       The  command  −v and −V options were added to satisfy requirements from
330       users that are currently accomplished  by  three  different  historical
331       utilities:  type  in  the  System V shell, whence in the KornShell, and
332       which in the C shell. Since there is no historical agreement on how and
333       what to accomplish here, the POSIX command utility was enhanced and the
334       historical utilities were left unmodified.  The C  shell  which  merely
335       conducts a path search. The KornShell whence is more elaborate—in addi‐
336       tion to the categories required by POSIX, it also  reports  on  tracked
337       aliases, exported aliases, and undefined functions.
338
339       The output format of −V was left mostly unspecified because human users
340       are its only audience.  Applications should  not  be  written  to  care
341       about  this information; they can use the output of −v to differentiate
342       between various types of commands, but the additional information  that
343       may  be  emitted by the more verbose −V is not needed and should not be
344       arbitrarily constrained in its verbosity or localization  for  applica‐
345       tion parsing reasons.
346

FUTURE DIRECTIONS

348       None.
349

SEE ALSO

351       Section 2.9.1.1, Command Search and Execution, Section 2.12, Shell Exe‐
352       cution Environment, Section 2.14, Special Built-In Utilities, sh, type
353
354       The Base Definitions volume of  POSIX.1‐2008,  Chapter  8,  Environment
355       Variables, Section 12.2, Utility Syntax Guidelines
356
357       The System Interfaces volume of POSIX.1‐2008, exec
358
360       Portions  of  this text are reprinted and reproduced in electronic form
361       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
362       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
363       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
364       cal  and  Electronics  Engineers,  Inc  and  The  Open Group.  (This is
365       POSIX.1-2008 with the 2013 Technical Corrigendum  1  applied.)  In  the
366       event of any discrepancy between this version and the original IEEE and
367       The Open Group Standard, the original IEEE and The Open Group  Standard
368       is  the  referee document. The original Standard can be obtained online
369       at http://www.unix.org/online.html .
370
371       Any typographical or formatting errors that appear  in  this  page  are
372       most likely to have been introduced during the conversion of the source
373       files to man page format. To report such errors,  see  https://www.ker
374       nel.org/doc/man-pages/reporting_bugs.html .
375
376
377
378IEEE/The Open Group                  2013                          COMMAND(1P)
Impressum