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

NAME

12       command - execute a simple command
13

SYNOPSIS

15       command [-p] command_name [argument ...]
16
17
18
19       command [ -v | -V ] command_name
20
21

DESCRIPTION

23       The command utility shall cause the shell to treat the arguments  as  a
24       simple command, suppressing the shell function lookup that is described
25       in Command Search and Execution, item 1b.
26
27       If the command_name is the same as the  name  of  one  of  the  special
28       built-in  utilities,  the  special properties in the enumerated list at
29       the beginning of Special Built-In Utilities shall not occur.  In  every
30       other  respect,  if  command_name  is  not  the name of a function, the
31       effect of command (with no options) shall be the same as omitting  com‐
32       mand.
33
34       On  systems  supporting the User Portability Utilities option, the com‐
35       mand utility also shall provide information concerning  how  a  command
36       name is interpreted by the shell; see -v and -V.
37

OPTIONS

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

OPERANDS

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

STDIN

110       Not used.
111

INPUT FILES

113       None.
114

ENVIRONMENT VARIABLES

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

ASYNCHRONOUS EVENTS

148       Default.
149

STDOUT

151       When the -v option is specified, standard output shall be formatted as:
152
153
154              "%s\n", <pathname or command>
155
156       When the -V option is specified, standard output shall be formatted as:
157
158
159              "%s\n", <unspecified>
160

STDERR

162       The standard error shall be used only for diagnostic messages.
163

OUTPUT FILES

165       None.
166

EXTENDED DESCRIPTION

168       None.
169

EXIT STATUS

171       When  the  -v  or  -V  options are specified, the following exit values
172       shall be returned:
173
174        0     Successful completion.
175
176       >0     The command_name could not be found or an error occurred.
177
178
179       Otherwise, the following exit values shall be returned:
180
181       126    The utility specified by command_name was found but could not be
182              invoked.
183
184       127    An  error  occurred in the command utility or the utility speci‐
185              fied by command_name could not be found.
186
187
188       Otherwise, the exit status of command shall be that of the simple  com‐
189       mand specified by the arguments to command.
190

CONSEQUENCES OF ERRORS

192       Default.
193
194       The following sections are informative.
195

APPLICATION USAGE

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

EXAMPLES

260        1. Make  a version of cd that always prints out the new working direc‐
261           tory exactly once:
262
263
264           cd() {
265               command cd "$@" >/dev/null
266               pwd
267           }
268
269        2. Start off a "secure shell script" in which the script avoids  being
270           spoofed by its parent:
271
272
273           IFS='
274           #    The preceding value should be <space><tab><newline>.
275           #    Set IFS to its default value.
276
277
278           \unalias -a
279           #    Unset all possible aliases.
280           #    Note that unalias is escaped to prevent an alias
281           #    being used for unalias.
282
283
284           unset -f command
285           #    Ensure command is not a user function.
286
287
288           PATH="$(command -p getconf _CS_PATH):$PATH"
289           #    Put on a reliable PATH prefix.
290
291
292           #    ...
293
294       At  this  point, given correct permissions on the directories called by
295       PATH,  the script has the ability to ensure that any utility  it  calls
296       is  the intended one. It is being very cautious because it assumes that
297       implementation extensions may be present that would  allow  user  func‐
298       tions  to exist when it is invoked; this capability is not specified by
299       this volume of IEEE Std 1003.1-2001, but it is  not  prohibited  as  an
300       extension.   For  example,  the ENV variable precedes the invocation of
301       the script with a user start-up script.  Such  a  script  could  define
302       functions to spoof the application.
303

RATIONALE

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

FUTURE DIRECTIONS

371       None.
372

SEE ALSO

374       Command Search and  Execution,  Shell  Execution  Environment,  Special
375       Built-In   Utilities,   sh,  type,  the  System  Interfaces  volume  of
376       IEEE Std 1003.1-2001, exec
377
379       Portions of this text are reprinted and reproduced in  electronic  form
380       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
381       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
382       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
383       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
384       event of any discrepancy between this version and the original IEEE and
385       The Open Group Standard, the original IEEE and The Open Group  Standard
386       is  the  referee document. The original Standard can be obtained online
387       at http://www.opengroup.org/unix/online.html .
388
389
390
391IEEE/The Open Group                  2003                          COMMAND(1P)
Impressum