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
11
13 command — execute a simple command
14
16 command [−p] command_name [argument...]
17
18 command [−p][−v|−V] command_name
19
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
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
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
105 Not used.
106
108 None.
109
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
140 Default.
141
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
152 The standard error shall be used only for diagnostic messages.
153
155 None.
156
158 None.
159
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
180 Default.
181
182 The following sections are informative.
183
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
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
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
348 None.
349
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)