18634
Comment: Fix issues. Removed most word-splitty line reading examples. ksh88 examples untested - going by the manual.
|
17662
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
This answer assumes you have a basic understanding of what arrays ''are''. If you're new to this kind of programming, you may wish to start with [[BashGuide/Arrays|the guide's explanation]]. This page is more thorough. See [[BashFAQ/005#See_Also|links]] at the bottom for more resources. | This answer assumes you have a basic understanding of what arrays ''are''. If you're new to this kind of programming, you may wish to start with [[BashGuide/Arrays|the guide's explanation]]. This page is more thorough. See [[#See_Also|links]] at the bottom for more resources. |
Line 9: | Line 9: |
Line 13: | Line 12: |
{{{ | {{{#!highlight bash |
Line 21: | Line 21: |
printf 'Host number %d is %s' "$idx" "${host[idx]}" | printf ' Host number %d is %s' "$idx" "${host[idx]}" |
Line 24: | Line 24: |
Line 29: | Line 28: |
{{{ | {{{#!highlight bash |
Line 38: | Line 37: |
# Unset the seceond element of "arr" | # Unset the second element of "arr" |
Line 41: | Line 40: |
# Concatenate the values, to a single argument separated by spaces, and echo the result. | # Concatenate the values, to a single argument separated by spaces, and echo the result. |
Line 45: | Line 44: |
Line 49: | Line 47: |
Line 52: | Line 49: |
{{{ | {{{#!highlight bash |
Line 57: | Line 54: |
Line 60: | Line 56: |
{{{ | {{{#!highlight bash |
Line 64: | Line 60: |
{{{ |
{{{#!highlight bash |
Line 69: | Line 64: |
Line 74: | Line 68: |
{{{ | {{{#!highlight bash |
Line 78: | Line 72: |
Line 81: | Line 74: |
{{{ | {{{#!highlight bash |
Line 85: | Line 78: |
{{{ |
{{{#!highlight bash |
Line 91: | Line 83: |
{{{ |
{{{#!highlight bash |
Line 96: | Line 87: |
Line 98: | Line 88: |
Line 101: | Line 90: |
{{{ | {{{#!highlight bash |
Line 108: | Line 97: |
Line 111: | Line 99: |
`mapfile` handles blank lines by inserting them as empty array elements, and also missing final newlines from the input stream. These can be problematic when reading data in other ways (see the next section). `mapfile` does have one serious drawback: it can ''only'' handle newlines as line terminators. Not all options supported by `read` are handled by `mapfile, and visa-versa. `mapfile` can't, for example, handle NUL-delimited files from `find -print0`. When mapfile isn't available, we have to work '''very hard''' to try to duplicate it. There are a great number of ways to ''almost'' get it right, but fail in subtle ways. | `mapfile` handles blank lines by inserting them as empty array elements, and also missing final newlines from the input stream. These can be problematic when reading data in other ways (see the next section). `mapfile` does have one serious drawback: it can ''only'' handle newlines as line terminators. Not all options supported by `read` are handled by `mapfile`, and visa-versa. `mapfile` can't, for example, handle NUL-delimited files from `find -print0`. When mapfile isn't available, we have to work '''very hard''' to try to duplicate it. There are a great number of ways to ''almost'' get it right, but fail in subtle ways. |
Line 115: | Line 103: |
{{{ # Bash, Ksh93, mksh |
{{{#!highlight bash # Bash 3.1, Ksh93, mksh |
Line 122: | Line 110: |
Line 125: | Line 112: |
{{{ # Korn |
{{{#!highlight bash # ksh88 |
Line 130: | Line 117: |
lines[i+=1,$i]=$REPLY | lines[i+=1,$i]=$REPLY # Mimics lines[i++]=$REPLY |
Line 134: | Line 121: |
Line 138: | Line 124: |
`read` returns false when it reads the last line of a file. This presents a problem: if the file contains a trailing newline, then `read` will be false when reading/assigning that final line, otherwise, it will be false when reading/assigning the last line of data. Without a special check for these cases, no matter what logic is used, you will always end up either with an extra blank element in the resulting array, or a missing final element. To be clear - most text files ''should'' contain a newline as the last character in the file. Newlines are added to the ends of files by most text editors, and also by [[HereDocument|Here documents]] and [[HereStromg|Here strings]]. Most of the time, this is only an issue when reading output from pipes or process substitutions, or from "broken" text files created with broken or misconfigured tools. Let's look at some examples. |
`read` returns false when it reads the last line of a file. This presents a problem: if the file contains a trailing newline, then `read` will be false when reading/assigning that final line, otherwise, it will be false when reading/assigning the last line of data. Without a special check for these cases, no matter what logic is used, you will always end up either with an extra blank element in the resulting array, or a missing final element. To be clear - text files ''should'' contain a newline as the last character in the file. Newlines are added to the ends of files by most text editors, and also by [[HereDocument|Here documents]] and [[HereStromg|Here strings]]. Most of the time, this is only an issue when reading output from pipes or process substitutions, or from "broken" text files created with broken or misconfigured tools. Let's look at some examples. |
Line 145: | Line 130: |
{{{ | {{{#!highlight bash |
Line 152: | Line 137: |
Line 155: | Line 139: |
{{{ | {{{#!highlight bash |
Line 162: | Line 146: |
Line 167: | Line 150: |
{{{ | {{{#!highlight bash |
Line 175: | Line 158: |
Line 180: | Line 162: |
{{{ | {{{#!highlight bash |
Line 190: | Line 172: |
Line 196: | Line 177: |
Line 199: | Line 179: |
{{{ | {{{#!highlight bash |
Line 203: | Line 183: |
{{{ |
{{{#!highlight bash |
Line 209: | Line 188: |
Unfortunately, the above doesn't work in ksh93, even though its `read` does have the ''-d'' delimiter flag. Of course, the above examples do not preserve blank lines, but they are a quick easy `mapfile` replacement that also works in a few non-bash shells. |
|
Line 212: | Line 189: |
'''[[DontReadLinesWithFor|NEVER READ LINES USING for..in LOOPS]]!''' Relying on [[IFS]] WordSplitting causes issues if you have repeated whitespace delimiters, because they will be consolidated. It is not possible to preserve blank lines by having them stored as empty array elements this way. Even worse, special globbing chracters will be expanded without going to lengths to disable and then re-enable it. Just never use this approach - it is problematic, the workarounds are all ugly, and not all problems are solvable. Because this is such an incredibly common mistake, below illustrates close to the best possible version of this hack, and how much harder it is than just doing it correctly -- and it still can't preserve consecutive newlines! It only gets worse from here. See DontReadLinesWithFor for details. {{{ # Bash # WARNING: Don't do this! evilReadLines() { [[ -e $2 ]] || return # Try hard to preserve the previous glob and trap states. # But if the caller sets ERR or DEBUG, we're still in trouble! if [[ $- != *f* ]]; then set -f local oReturn=$(trap -p RETURN) trap 'set +f; trap "${oReturn:--}" RETURN' RETURN fi local line idx IFS=$'\n' for line in ${1:+$(<"$2")}; do printf -v "$1" "$line" done # This is an equally bad alternative to the above for loop, albeit slightly faster: # IFS=$'\n' declare -a ${1:+"$1"'=( $(<"$2") )'} 2>/dev/null } declare -ft evilReadLines # Inherit traps from the caller. # Pass in an array name and file name evilReadLines myArray myFile }}} |
'''[[DontReadLinesWithFor|Never read lines using for..in loops]]!''' Relying on [[IFS]] WordSplitting causes issues if you have repeated whitespace delimiters, because they will be consolidated. It is not possible to preserve blank lines by having them stored as empty array elements this way. Even worse, special globbing characters will be expanded without going to lengths to disable and then re-enable it. Just never use this approach - it is problematic, the workarounds are all ugly, and not all problems are solvable. |
Line 247: | Line 192: |
Line 250: | Line 194: |
{{{ # Bash unset -v arr i while IFS= read -rd '' 'arr[i++]'; do : done < <(find . -name '*.ugly' -print0) if [[ ${arr[i-1]} = "" ]]; then unset 'arr[--i]'; fi # or |
{{{#!highlight bash # Bash |
Line 262: | Line 199: |
[[ $REPLY ]] && arr[i++]=$REPLY }}} `read -d ''` tells Bash to keep reading until a NUL byte instead of until a newline. As with the alternate method for reading lines using `read -ra` discussed in a previous section, there is no equivalent in ksh93 as far as we're aware. mksh and zsh do not have these problems with their respective -d options. |
# or (bash 3.1 and up) while read -rd ''; do arr+=("$REPLY") done < <(find . -name '*.ugly' -print0) }}} `read -d ''` tells Bash to keep reading until a NUL byte instead of until a newline. This isn't certain to work in all shells with a `-d` feature. |
Line 268: | Line 208: |
Line 273: | Line 212: |
{{{ | {{{#!highlight bash |
Line 277: | Line 216: |
Line 280: | Line 218: |
{{{ | {{{#!highlight bash |
Line 285: | Line 223: |
Line 288: | Line 225: |
{{{ | {{{#!highlight bash |
Line 295: | Line 232: |
Line 298: | Line 234: |
{{{ | {{{#!highlight bash |
Line 302: | Line 238: |
Line 308: | Line 243: |
Line 311: | Line 245: |
{{{ | {{{#!highlight bash |
Line 317: | Line 251: |
Line 320: | Line 253: |
{{{ | {{{#!highlight bash |
Line 323: | Line 256: |
Line 326: | Line 258: |
{{{ | {{{#!highlight bash |
Line 329: | Line 261: |
Line 334: | Line 265: |
{{{ | {{{#!highlight bash |
Line 340: | Line 271: |
Line 345: | Line 275: |
{{{ | {{{#!highlight bash |
Line 349: | Line 279: |
Line 352: | Line 281: |
{{{ | {{{#!highlight bash |
Line 358: | Line 287: |
Line 361: | Line 289: |
{{{ | {{{#!highlight bash |
Line 368: | Line 296: |
Line 371: | Line 298: |
{{{ | {{{#!highlight bash |
Line 377: | Line 304: |
Line 382: | Line 308: |
{{{ | {{{#!highlight bash |
Line 389: | Line 315: |
Line 392: | Line 317: |
{{{ | {{{#!highlight bash |
Line 408: | Line 333: |
Line 410: | Line 334: |
Line 413: | Line 336: |
{{{ | {{{#!highlight bash |
Line 419: | Line 342: |
Line 422: | Line 344: |
{{{ | {{{#!highlight bash |
Line 426: | Line 348: |
echo "${@:(-1)}" # last positional parameter echo "${@:(-2):1}" # second-to-last positional parameter |
}}} The same goes for positional parameters {{{#!highlight bash set -- foo bar baz echo "${@:(-1)}" # last positional parameter baz echo "${@:(-2):1}" # second-to-last positional parameter bar |
Line 431: | Line 359: |
Line 434: | Line 361: |
{{{ | {{{#!highlight bash |
Line 443: | Line 370: |
{{{ |
{{{#!highlight bash |
Line 452: | Line 378: |
Line 456: | Line 381: |
* [[http://wiki.bash-hackers.org/syntax/arrays|Bash-hackers array documentation]] * [[BashGuide/Arrays]] * [[BashSheet#Arrays|BashSheet Array reference]] * [[BashFAQ/006#Associative_Arrays|BashFAQ 6 - explaining associative arrays]] |
* [[http://wiki.bash-hackers.org/syntax/arrays|Bash-hackers array documentation]] * [[BashGuide/Arrays]] * [[BashSheet#Arrays|BashSheet Array reference]] * [[BashFAQ/006#Associative_Arrays|BashFAQ 6 - explaining associative arrays]] |
How can I use array variables?
This answer assumes you have a basic understanding of what arrays are. If you're new to this kind of programming, you may wish to start with the guide's explanation. This page is more thorough. See links at the bottom for more resources.
Contents
1. Intro
One-dimensional integer-indexed arrays are implemented by Bash, Zsh, and most KornShell varieties including AT&T ksh88 or later, mksh, and pdksh. Arrays are not specified by POSIX and not available in legacy or minimalist shells such as BourneShell and Dash. The POSIX-compatible shells that do feature arrays mostly agree on their basic principles, but there are some significant differences in the details. Advanced users of multiple shells should be sure to research the specifics. Ksh93, Zsh, and Bash 4.0 additionally have Associative Arrays. This article focuses on indexed arrays as they are the most common and useful type.
Here is a typical usage pattern featuring an array named host:
"${!host[@]}" expands to the indices of of the host array, each as a separate argument. (We'll go into more detail on syntax below.)
Indexed arrays are sparse, and elements may be inserted and deleted out of sequence.
1 # Bash/ksh
2
3 # Simple assignment syntax.
4 arr[0]=0
5 arr[2]=2
6 arr[1]=1
7 arr[42]='what was the question?'
8
9 # Unset the second element of "arr"
10 unset -v 'arr[2]'
11
12 # Concatenate the values, to a single argument separated by spaces, and echo the result.
13 echo "${arr[*]}"
14 # outputs: "0 1 what was the question?"
It is good practice to write your code in such a way that it can handle sparse arrays, even if you think you can guarantee that there will never be any "holes". Only treat arrays as "lists" if you're certain, and the savings in complexity is significant enough for it to be justified.
2. Loading values into an array
Assigning one element at a time is simple, and portable:
It's possible to assign multiple values to an array at once, but the syntax differs across shells. Bash supports only the arrName=(args...) syntax. ksh88 supports only the set -A arrName -- args... syntax. ksh93, mksh, and zsh support both. There are subtle differences in both methods between all of these shells if you look closely.
When initializing in this way, the first index will be 0 unless a different index is specified.
With compound assignment, the space between the parentheses is evaluated in the same way as the arguments to a command, including pathname expansion and WordSplitting. Any type of expansion or substitution may be used. All the usual quoting rules apply within.
With ksh88-style assignment using set, the arguments are just ordinary arguments to a command.
2.1. Loading lines from a file or stream
In bash 4, the mapfile command (also known as readarray) accomplishes this:
See ProcessSubstitution and FAQ #24 for more details on the <(...) syntax.
mapfile handles blank lines by inserting them as empty array elements, and also missing final newlines from the input stream. These can be problematic when reading data in other ways (see the next section). mapfile does have one serious drawback: it can only handle newlines as line terminators. Not all options supported by read are handled by mapfile, and visa-versa. mapfile can't, for example, handle NUL-delimited files from find -print0. When mapfile isn't available, we have to work very hard to try to duplicate it. There are a great number of ways to almost get it right, but fail in subtle ways.
These examples will duplicate most of mapfile's basic functionality:
The += operator, when used together with parentheses, appends the element to one greater than the current highest numbered index in the array.
The square brackets create a math context. The result of the expression is the index used for assignment.
2.1.1. Handling newlines (or lack thereof) at the end of a file
read returns false when it reads the last line of a file. This presents a problem: if the file contains a trailing newline, then read will be false when reading/assigning that final line, otherwise, it will be false when reading/assigning the last line of data. Without a special check for these cases, no matter what logic is used, you will always end up either with an extra blank element in the resulting array, or a missing final element.
To be clear - text files should contain a newline as the last character in the file. Newlines are added to the ends of files by most text editors, and also by Here documents and Here strings. Most of the time, this is only an issue when reading output from pipes or process substitutions, or from "broken" text files created with broken or misconfigured tools. Let's look at some examples.
This approach reads the elements one by one, using a loop.
Unfortunately, if the file or input stream contains a trailing newline, a blank element is added at the end of the array, because the read -r arr[i++] is executed one extra time after the last line containing text before returning false.
The square brackets create a math context. Inside them, i++ works as a C programmer would expect (in all but ksh88).
This approach fails in the reverse case - it correctly handles blank lines and inputs terminated with a newline, but fails to record the last line of input. If the file or stream is missing its final newline. So we need to handle that case specially:
This is very close to the "final solution" we gave earlier -- handling both blank lines inside the file, and an unterminated final line. The null IFS is used to prevent read from stripping possible whitespace from the beginning and end of lines, in the event you wish to preserve them.
Another workaround is to remove the empty element after the loop:
Whether you prefer to read too many and then have to remove one, or read too few and then have to add one, is a personal choice.
NOTE: it is necessary to quote the 'arr[i++]' passed to read, so that the square brackets aren't interpreted as globs. This is also true for other non-keyword builtins that take a subscripted variable name, such as let and unset.
2.1.2. Other methods
Sometimes stripping blank lines actually is desirable, or you may know that the input will always be newline delimited, such as input generated internally by your script. It is possible in some shells to use the -d flag to set read's line delimiter to null, then abuse the -a or -A (depending on the shell) flag normally used for reading the fields of a line into an array for reading lines. Effectively, the entire input is treated as a single line, and the fields are newline-delimited.
2.1.3. Don't read lines with for!
Never read lines using for..in loops! Relying on IFS WordSplitting causes issues if you have repeated whitespace delimiters, because they will be consolidated. It is not possible to preserve blank lines by having them stored as empty array elements this way. Even worse, special globbing characters will be expanded without going to lengths to disable and then re-enable it. Just never use this approach - it is problematic, the workarounds are all ugly, and not all problems are solvable.
2.2. Reading NUL-delimited streams
If you are trying to deal with records that might have embedded newlines, you will be using an alternative delimiter such as the NUL character ( \0 ) to separate the records. In that case, you'll need to use the -d argument to read as well:
read -d '' tells Bash to keep reading until a NUL byte instead of until a newline. This isn't certain to work in all shells with a -d feature.
2.3. Appending to an existing array
As previously mentioned, arrays are sparse - that is, numerically adjacent indexes are not guaranteed to be occupied by a value. This confuses what it means to "append" to an existing array. There are several approaches.
If you've been keeping track of the highest-numbered index with a variable (for example, as a side-effect of populating an array in a loop), and can guarantee it's correct, you can just use it and continue to ensure it remains in-sync.
If you don't want to keep an index variable, but happen to know that your array is not sparse, then you can use the number of elements to calculate the offset (not recommended):
If you don't know whether your array is sparse or not, but don't mind re-indexing the entire array (very inefficient), then you can use:
If you're in bash 3.1 or higher, then you can use the += operator:
NOTE: the parentheses are required, just as when assigning to an array. Otherwise you will end up appending to ${arr[0]} which $arr is a synonym for. If your shell supports this type of appending, it is the preferred method.
For examples of using arrays to hold complex shell commands, see FAQ #50 and FAQ #40.
3. Retrieving values from an array
${#arr[@]} or ${#arr[*]} expand to the number of elements in an array:
Single elements are retrieved by index:
1 echo "${foo[0]} - ${bar[j+1]}"
The square brackets are a math context. Within an arithmetic context, variables, including arrays, can be referenced by name. For example, in the expansion:
1 ${arr[x[3+arr[2]]]}
arr's index will be the value from the array x whose index is 3 plus the value of arr[2].
Using array elements en masse is one of the key features of shell arrays. In exactly the same way that "$@" is expanded for positional parameters, "${arr[@]}" is expanded to a list of words, one array element per word. For example,
This works even if the elements contain whitespace. You always end up with the same number of words as you have array elements.
If one simply wants to dump the full array, one element per line, this is the simplest approach:
For slightly more complex array-dumping, "${arr[*]}" will cause the elements to be concatenated together, with the first character of IFS (or a space if IFS isn't set) between them. As it happens, "$*" is expanded the same way for positional parameters.
Unfortunately, you can't put multiple characters in between array elements using that syntax. You would have to do something like this instead:
Or using array slicing, described in the next section.
This also shows how sparse arrays can be assigned multiple elements at once. Note using the arr=([key]=value ...) notation differs between shells. In ksh93, this syntax gives you an associative array by default unless you specify otherwise, and using it requires that every value be explicitly given an index, unlike bash, where omitted indexes begin at the previous index. This example was written in a way that's compatible between the two.
BASH 3.0 added the ability to retrieve the list of index values in an array:
Retrieving the indices is extremely important for certain kinds of tasks, such as maintaining parallel arrays with the same indices (a cheap way to mimic having an array of structs in a language with no struct):
1 # Bash 3.0 or higher
2 unset file title artist i
3 for f in ./*.mp3; do
4 file[i]=$f
5 title[i]=$(mp3info -p %t "$f")
6 artist[i++]=$(mp3info -p %a "$f")
7 done
8
9 # Later, iterate over every song.
10 # This works even if the arrays are sparse, just so long as they all have
11 # the SAME holes.
12 for i in "${!file[@]}"; do
13 echo "${file[i]} is ${title[i]} by ${artist[i]}"
14 done
3.1. Retrieving with modifications
Bash's Parameter Expansions may be performed on array elements en masse:
Parameter Expansion can also be used to extract elements from an array. Some people call this slicing:
The same goes for positional parameters
4. Using @ as a pseudo-array
As we see above, the @ array (the array of positional parameters) can be used almost like a regularly named array. This is the only array available for use in POSIX or Bourne shells. It has certain limitations: you cannot individually set or unset single elements, and it cannot be sparse. Nevertheless, it still makes certain POSIX shell tasks possible that would otherwise require external tools:
(Compare to FAQ #50's dynamically generated commands using named arrays.)