1 .\" $OpenBSD: script.7,v 1.4 2007/05/31 19:19:58 jmc Exp $
3 .\" $NetBSD: script.7,v 1.1 2005/05/07 02:20:34 perry Exp $
4 .\" $DragonFly: src/share/man/man7/script.7,v 1.2 2007/12/22 19:07:00 swildner Exp $
6 .\" Copyright (c) 2005 The NetBSD Foundation, Inc.
7 .\" All rights reserved.
9 .\" This document was originally contributed to The NetBSD Foundation
10 .\" by Perry E. Metzger of Metzger, Dowdeswell & Co. LLC.
12 .\" Redistribution and use in source and binary forms, with or without
13 .\" modification, are permitted provided that the following conditions
15 .\" 1. Redistributions of source code must retain the above copyright
16 .\" notice, this list of conditions and the following disclaimer.
17 .\" 2. Redistributions in binary form must reproduce the above copyright
18 .\" notice, this list of conditions and the following disclaimer in the
19 .\" documentation and/or other materials provided with the distribution.
20 .\" 3. All advertising materials mentioning features or use of this software
21 .\" must display the following acknowledgement:
22 .\" This product includes software developed by the NetBSD
23 .\" Foundation, Inc. and its contributors.
24 .\" 4. Neither the name of The NetBSD Foundation nor the names of its
25 .\" contributors may be used to endorse or promote products derived
26 .\" from this software without specific prior written permission.
28 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
29 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
30 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
31 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
32 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
33 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
34 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
35 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
36 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
37 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
38 .\" POSSIBILITY OF SUCH DAMAGE.
45 .Nd interpreter script execution
47 The system is capable of treating a text file containing commands
48 intended for an interpreter, such as
52 as an executable program.
55 .Dq interpreter script
56 is a file which has been set executable (see
58 and which has a first line of the form:
60 .D1 Li #! Ar pathname Op Ar argument
64 must appear as the first two characters of the file.
74 and the length of the entire line is limited (see below).
76 If such a file is executed (such as via the
78 system call), the interpreter specified by the
80 is executed by the system.
83 is executed without regard to the
85 variable, so in general
87 should be an absolute path.)
89 The arguments passed to the interpreter will be as follows.
91 will be the path to the interpreter itself, as specified on the first
97 on the first line of the script, it will be passed as
99 The subsequent elements of
101 will be the path to the interpreter script file itself (i.e. the
104 followed by any further arguments passed when
106 was invoked to execute the script file.
108 By convention, it is expected that an interpreter will open the script
109 file passed as an argument and process the commands within it.
110 Typical interpreters treat
112 as a comment character, and thus will ignore the initial line of the script
115 but there is no requirement for this per se.
123 itself, is limited to
127 Other operating systems impose different limits on the length of
132 Note that the interpreter may not itself be an interpreter script.
135 does not point to an executable binary, execution of the interpreter
137 .Ss Trampolines and Portable Scripts
138 Different operating systems often have interpreters located in
139 different locations, and the kernel executes the passed interpreter
140 without regard to the setting of environment variables such as
142 This makes it somewhat challenging to set the
144 line of a script so that it will run identically on different systems.
148 utility executes a command passed to it on its command line, it is
151 to render scripts portable.
152 If the leading line of a script reads
154 .Dl #! /usr/bin/env interp
158 command will execute the
160 command it finds in its
162 passing on to it all subsequent arguments with which it itself was called.
165 is found on almost all
167 style systems, this trick is frequently exploited by authors who need
168 a script to execute without change on multiple systems.
169 .Ss Historical Note: Scripts without `#!'
170 Shell scripts predate the invention of the
172 convention, which is implemented in the kernel.
175 there was only one interpreter used on the system,
177 and the shell treated any file that failed to execute with an
186 and certain other facilities (including
190 but not other types of
193 interpreter scripts that do not include the
195 (and thus fail to execute with
200 As this behavior is implemented outside the kernel, there is no
201 mechanism that forces it to be respected by all programs that execute
203 It is thus not completely reliable.
204 It is therefore important to always include
208 in front of Bourne shell scripts, and to treat the traditional
209 behavior as obsolete.
211 Suppose that an executable binary exists in
216 .Bd -literal -offset indent
228 .Dl $ /tmp/script one two three
230 at the shell will result in
232 being executed, receiving the following arguments in
235 .Bd -ragged -offset indent
243 .Ss Portability Note: Multiple arguments
244 The behavior of multiple arguments on the
246 line is highly non-portable between different systems.
247 In general, only one argument can be assumed to work consistently.
249 Consider the following variation on the previous example.
250 Suppose that an executable binary exists in
255 .Bd -literal -offset indent
267 .Dl $ /tmp/script one two three
269 at the shell will result in
271 being executed, receiving the following arguments in
274 .Bd -ragged -offset indent
287 as a single argument.
291 style operating systems will pass only one
293 the behavior when multiple arguments are included is not
294 consistent between platforms.
297 will concatenate multiple arguments into a single argument (as above),
298 some will truncate them, and at least one will pass them as multiple
303 behavior is common but not universal.
306 would present the above argument as
311 Perhaps uniquely, recent versions of Apple's
313 will actually pass multiple arguments properly, i.e.:
314 .Bd -ragged -offset indent
324 The behavior of the system in the face of multiple arguments is thus
325 not currently standardized, should not be relied on, and may be
326 changed in future releases.
327 In general, pass at most one argument, and do not rely on multiple
328 arguments being concatenated.
339 The behavior of interpreter scripts is obliquely referred to, but
340 never actually described in,
343 The behavior is partially (but not completely) described in the
346 Although it has never been formally standardized, the behavior
347 described is largely portable across
349 style systems, with two significant exceptions: the maximum length of the
351 line, and the behavior if multiple arguments are passed.
352 Please be aware that the behavior in the
353 face of multiple arguments is not consistent across systems.
355 The behavior of the kernel when encountering scripts that start in
359 A Usenet posting to net.unix by Guy Harris on October 16, 1984 claims
360 that the idea for the
362 behavior was first proposed by Dennis Ritchie but that the first
363 implementation was on
366 Historical manuals (specifically the exec man page) indicate that the
367 behavior was present in
369 at least as early as April, 1981.
370 Information on precisely when it was first implemented, and in which
375 Numerous security problems are associated with setuid interpreter
378 In addition to the fact that many interpreters (and scripts) are
379 simply not designed to be robust in a setuid context, a race condition
380 exists between the moment that the kernel examines the interpreter
381 script file and the moment that the newly invoked interpreter opens
384 Subtle techniques can be used to subvert even seemingly well written scripts.
385 Scripts executed by Bourne type shells can be subverted in numerous
386 ways, such as by setting the
388 variable before executing the script.
389 Other interpreters possess their own vulnerabilities.
390 Setting the Set-user-ID on execution (SUID) bit
391 is therefore very dangerous, and should not be done lightly, if at all.