1COMMAND(1P) POSIX Programmer's Manual COMMAND(1P)
2
3
4
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
12 command - execute a simple command
13
15 command [-p] command_name [argument ...]
16
17
18
19 command [ -v | -V ] command_name
20
21
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
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
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
110 Not used.
111
113 None.
114
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
148 Default.
149
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
162 The standard error shall be used only for diagnostic messages.
163
165 None.
166
168 None.
169
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
192 Default.
193
194 The following sections are informative.
195
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
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
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
371 None.
372
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)