Differences

This shows you the differences between two versions of the page.

--- bash:wordsplitting [2021/01/09 15:35] – peter
+++ bash:wordsplitting [2021/01/09 15:51] (current) – [Controlling Word Splitting] peter
@@ Line 70: / Line 70: @@
 ----
-===== IFS =====
+===== Test when IFS is not SET =====
-Word splitting is performed on the results of almost all unquoted expansions.
-The result of the expansion is broken into separate words based on the characters of the IFS variable.
 If IFS is not set, then it will be performed as if IFS contained a space, a tab, and a newline.
@@ Line 82: / Line 78: @@
 <code bash>
 var="This is a variable"
-args $var
+test.sh $var
+</code>
+returns:
+<code bash>
 args: <This> <is> <a> <variable>
 </code>
 ----
+===== Test when IFS is SET =====
 An example using IFS:
@@ Line 92: / Line 95: @@
 <code bash>
 log=/var/log/qmail/current IFS=/
-args $log
+test.sh $log
+</code>
+returns:
+<code bash>
 args: <> <var> <log> <qmail> <current>
 unset IFS
@@ Line 99: / Line 107: @@
 ----
-An example with CommandSubstitution:
+===== Test with Command Substitution =====
 <code bash>
 ls -l
+</code>
+returns:
+<code bash>
 total 2864
 -rw-r--r-- 1 greg greg 2919154 2001-05-23 00:48 Yello - Oh Yeah.mp3
+</code>
-args $(ls -l)
+Now run against the test script:
+<code bash>
+test.sh $(ls -l)
+</code>
+returns:
+<code bash>
 args: <-rw-r--r--> <1> <greg> <greg> <2919154> <2001-05-23> <00:48> <Yello> <-> <Oh> <Yeah.mp3>
 </code>
@@ Line 114: / Line 136: @@
 ===== Controlling Word Splitting =====
-As you can see above, we usually do not want to let word splitting occur when filenames are involved. (See BashPitfalls for a discussion of this particular issue.)
+As you can see above, we usually do not want to let word splitting occur when filenames are involved.
-Double quoting an expansion suppresses word splitting, except in the special cases of "$@" and "${array[@]}":
+Double quoting an expansion suppresses word splitting, except in the special cases of <nowiki>"$@"</nowiki> and <nowiki>"${array[@]}"</nowiki>:
+<code bash>
+var="This is a variable"; test.sh "$var"
+</code>
+returns:
 <code bash>
-var="This is a variable"; args "$var"
 args: <This is a variable>
+</code>
-array=(testing, testing, "1 2 3"); args "${array[@]}"
+----
+<code bash>
+array=(testing, testing, "1 2 3"); test.sh "${array[@]}"
+</code>
+returns:
+<code bash>
 args: <testing,> <testing,> <1 2 3>
 </code>
-"$@" causes each positional parameter to be expanded to a separate word; its array equivalent likewise causes each element of the array to be expanded to a separate word.
+<WRAP info>
+**NOTE:**  **<nowiki>"$@"</nowiki>** causes each positional parameter to be expanded to a separate word; its array equivalent likewise causes each element of the array to be expanded to a separate word.
 There are very complicated rules involving whitespace characters in IFS. Quoting the man page again:
@@ Line 137: / Line 174: @@
 We won't explore those rules in depth here, except to note the part about sequences of non-whitespace characters.
+</WRAP>
+----
+===== IFS with non-whitespace characters =====
 If IFS contains non-whitespace characters, then empty words can be generated:
@@ Line 142: / Line 185: @@
 <code bash>
 getent passwd sshd
+</code>
+returns:
+<code bash>
 sshd:x:100:65534::/var/run/sshd:/usr/sbin/nologin
+</code>
-IFS=:; args $(getent passwd sshd)
+----
+Set IFS
+<code bash>
+IFS=:; test.sh $(getent passwd sshd)
+</code>
+returns:
+<code bash>
 args: <sshd> <x> <100> <65534> <> </var/run/sshd> </usr/sbin/nologin>
+</code>
+Unset IFS
+<code bash>
 unset IFS
 </code>
-There was another empty word generated in one of our previous examples, where IFS was set to /.  The observant reader will have noticed, therefore, that non-whitespace IFS characters are not ignored at the beginning and end of expansions, the way whitespace IFS characters are.
+<WRAP info>
+**NOTE:**  There was another empty word generated in one of our previous examples, where IFS was set to **/**.
+  * non-whitespace IFS characters are not ignored at the beginning and end of expansions, the way whitespace IFS characters are.
+Whitespace IFS characters get consolidated.
+  * Multiple spaces in a row, for example, have the same effect as a single space, when IFS contains a space (or is not set at all).
+  * Newlines also count as whitespace for this purpose, which has important ramifications when attempting to load an array with lines of input.
-Whitespace IFS characters get consolidated.  Multiple spaces in a row, for example, have the same effect as a single space, when IFS contains a space (or is not set at all).  Newlines also count as whitespace for this purpose, which has important ramifications when attempting to load an array with lines of input.
+</WRAP>
-Finally, we note that pathname expansion happens after word splitting, and can produce some very shocking results.
+Pathname expansion happens after word splitting, and can produce some very shocking results:
 <code bash>
@@ Line 160: / Line 231: @@
 qmaild:*:994:998::/var/qmail:/sbin/nologin
-IFS=:; args $(getent passwd qmaild)
+IFS=:; test $(getent passwd qmaild)
 args: <qmaild> <00INDEX.lsof> <03> <037_ftpd.patch> ...
@@ Line 166: / Line 237: @@
 </code>
-The * word, produced by the shell's word splitting, was then expanded as a glob, resulting in several hundred new and exciting words.  This can be disastrous if it happens unexpectedly.  As with most of the dangerous features of the shell, it is retained because "it's always worked that way".  In fact, it can be used for good, if you're very careful:
+The **<nowiki>*</nowiki>** word, produced by the shell's word splitting, was then expanded as a glob, resulting in several hundred new and exciting words.
+  * This can be disastrous if it happens unexpectedly.
+  * As with most of the dangerous features of the shell, it is retained because "it's always worked that way".
+  * In fact, it can be used for good, if you're very careful:
 <code bash>
 files='*.mp3 *.ogg'
-args $files
+test.sh $files
 args: <Yello - Oh Yeah.mp3> <*.ogg>
 </code>
-Pathname expansion can be disabled with set -f or set -o noglob; though this can lead to surprising and confusing code.
+<WRAP info>
+**NOTE:**  Pathname expansion can be disabled with set -f or set -o noglob; though this can lead to surprising and confusing code.
+</WRAP>
 ----