pmodules/bash
0
0
Fork 0
mirror of https://https.git.savannah.gnu.org/git/bash.git synced 2026-06-30 00:49:57 +02:00
Code Issues Packages Projects Releases Wiki Activity

documentation tweaks for clarity

Browse Source
This commit is contained in:
Chet Ramey
2021-03-22 11:16:34 -04:00
parent 6be3a741cb
commit b37342db4f
6 changed files with 1591 additions and 1396 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CWRU/CWRU.chlog
+10
View File
@@ -9895,3 +9895,13 @@ doc/{bash.1,bashref.texi}
- {pushd,popd}: make it clear that these builtins use cd to change
the current working directory; change wording to simplify the
description and clarify the exit status
3/18
----
execute_cmd.c
- execute_disk_command: after performing redirections, call
unlink_all_fifos() to remove the FIFOs created as part of
expanding redirections. They should have been opened by then, and
we're going to call shell_execve right away anyway, so we won't be
around to remove the FIFOs. From a report from
Michael Felt <aixtools@gmail.com>
doc/bash.0
+1175 -1160
View File
File diff suppressed because it is too large Load Diff
doc/bash.1
+7 -5
View File
@@ -751,12 +751,14 @@ If the
.B nocasematch
shell option is enabled, the match is performed without regard to the case
of alphabetic characters.
Any part of the pattern may be quoted to force the quoted portion
to be matched as a string.
Bracket expressions in regular expressions must be treated carefully,
since normal quoting characters lose their meanings between brackets.
If any part of the pattern is quoted, the quoted portion is matched literally.
This means every character in the quoted portion matches itself,
instead of having any special pattern matching meaning.
If the pattern is stored in a shell variable, quoting the variable
expansion forces the entire pattern to be matched as a string.
expansion forces the entire pattern to be matched literally.
Treat bracket expressions in regular expressions carefully,
since normal quoting and pattern characters lose their meanings
between brackets.
.if t .sp 0.5
.if n .sp 1
The pattern will match if it matches any part of the string.
doc/bashref.info
+282 -188
View File
@@ -913,67 +913,92 @@ File: bashref.info, Node: Conditional Constructs, Next: Command Grouping, Pre
'shopt' in *note The Shopt Builtin::) is enabled, the match is
performed without regard to the case of alphabetic characters. The
return value is 0 if the string matches ('==') or does not match
('!=') the pattern, and 1 otherwise. Any part of the pattern may
be quoted to force the quoted portion to be matched as a string.
('!=') the pattern, and 1 otherwise.
If you quote any part of the pattern, using any of the shell's
quoting mechanisms, the quoted portion is matched literally. This
means every character in the quoted portion matches itself, instead
of having any special pattern matching meaning.
An additional binary operator, '=~', is available, with the same
precedence as '==' and '!='. When it is used, the string to the
precedence as '==' and '!='. When you use '=~', the string to the
right of the operator is considered a POSIX extended regular
expression and matched accordingly (using the POSIX 'regcomp' and
'regexec' interfaces usually described in regex(3)). The return
value is 0 if the string matches the pattern, and 1 otherwise. If
the regular expression is syntactically incorrect, the conditional
expression's return value is 2. If the 'nocasematch' shell option
(see the description of 'shopt' in *note The Shopt Builtin::) is
enabled, the match is performed without regard to the case of
alphabetic characters. Any part of the pattern may be quoted to
force the quoted portion to be matched as a string. Bracket
expressions in regular expressions must be treated carefully, since
normal quoting characters lose their meanings between brackets. If
the pattern is stored in a shell variable, quoting the variable
expansion forces the entire pattern to be matched as a string.
expression pattern and matched accordingly (using the POSIX
'regcomp' and 'regexec' interfaces usually described in regex(3)).
The return value is 0 if the string matches the pattern, and 1 if
it does not. If the regular expression is syntactically incorrect,
the conditional expression returns 2. If the 'nocasematch' shell
option (see the description of 'shopt' in *note The Shopt
Builtin::) is enabled, the match is performed without regard to the
case of alphabetic characters.
The pattern will match if it matches any part of the string.
Anchor the pattern using the '^' and '$' regular expression
operators to force it to match the entire string. The array
variable 'BASH_REMATCH' records which parts of the string matched
the pattern. The element of 'BASH_REMATCH' with index 0 contains
the portion of the string matching the entire regular expression.
Substrings matched by parenthesized subexpressions within the
regular expression are saved in the remaining 'BASH_REMATCH'
indices. The element of 'BASH_REMATCH' with index N is the portion
of the string matching the Nth parenthesized subexpression.
You can quote any part of the pattern to force the quoted portion
to be matched literally instead of as a regular expression (see
above). If the pattern is stored in a shell variable, quoting the
variable expansion forces the entire pattern to be matched
literally.
The pattern will match if it matches any part of the string. If
you want to force the pattern to match the entire string, anchor
the pattern using the '^' and '$' regular expression operators.
For example, the following will match a line (stored in the shell
variable LINE) if there is a sequence of characters anywhere in the
value consisting of any number, including zero, of characters in
the 'space' character class, zero or one instances of 'a', then a
'b':
variable 'line') if there is a sequence of characters anywhere in
the value consisting of any number, including zero, of characters
in the 'space' character class, immediately followed by zero or one
instances of 'a', then a 'b':
[[ $line =~ [[:space:]]*(a)?b ]]
That means values like 'aab' and ' aaaaaab' will match, as will a
line containing a 'b' anywhere in its value.
That means values for 'line' like 'aab', ' aaaaaab', 'xaby', and '
ab' will all match, as will a line containing a 'b' anywhere in its
value.
If you want to match a character that's special to the regular
expression grammar ('^$|[]()\.*+?'), it has to be quoted to remove
its special meaning. This means that in the pattern 'xxx.txt', the
'.' matches any character in the string (its usual regular
expression meaning), but in the pattern '"xxx.txt"', it can only
match a literal '.'.
Likewise, if you want to include a character in your pattern that
has a special meaning to the regular expression grammar, you must
make sure it's not quoted. If you want to anchor a pattern at the
beginning or end of the string, for instance, you cannot quote the
'^' or '$' characters using any form of shell quoting.
If you want to match 'initial string' at the start of a line, the
following will work:
[[ $line =~ ^"initial string" ]]
but this will not:
[[ $line =~ "^initial string" ]]
because in the second example the '^' is quoted and doesn't have
its usual special meaning.
It is sometimes difficult to specify a regular expression properly
without using quotes, or to keep track of the quoting used by
regular expressions while paying attention to shell quoting and the
shell's quote removal. Storing the regular expression in a shell
variable is often a useful way to avoid problems with quoting
characters that are special to the shell. For example, the
following is equivalent to the pattern used above:
Storing the regular expression in a shell variable is often a
useful way to avoid problems with quoting characters that are
special to the shell. It is sometimes difficult to specify a
regular expression literally without using quotes, or to keep track
of the quoting used by regular expressions while paying attention
to the shell's quote removal. Using a shell variable to store the
pattern decreases these problems. For example, the following is
equivalent to the above:
pattern='[[:space:]]*(a)?b'
[[ $line =~ $pattern ]]
If you want to match a character that's special to the regular
expression grammar, it has to be quoted to remove its special
meaning. This means that in the pattern 'xxx.txt', the '.' matches
any character in the string (its usual regular expression meaning),
but in the pattern '"xxx.txt"' it can only match a literal '.'.
Shell programmers should take special care with backslashes, since
backslashes are used by both the shell and regular expressions to
remove the special meaning from the following character. The
following two sets of commands are _not_ equivalent:
remove the special meaning from the following character. This
means that after the shell's word expansions complete (*note Shell
Expansions::), any backslashes remaining in parts of the pattern
that were originally not quoted can remove the special meaning of
pattern characters. If any part of the pattern is quoted, the
shell does its best to ensure that the regular expression treats
those remaining backslashes as literal, if they appeared in a
quoted portion.
The following two sets of commands are _not_ equivalent:
pattern='\.'
[[ . =~ $pattern ]]
@@ -984,12 +1009,46 @@ File: bashref.info, Node: Conditional Constructs, Next: Command Grouping, Pre
The first two matches will succeed, but the second two will not,
because in the second two the backslash will be part of the pattern
to be matched. In the first two examples, the backslash removes
the special meaning from '.', so the literal '.' matches. If the
to be matched. In the first two examples, the pattern passed to
the regular expression parser is '\.'. The backslash removes the
special meaning from '.', so the literal '.' matches. In the
second two examples, the pattern passed to the regular expression
parser has the backslash quoted (e.g., '\\\.'), which will not
match the string, since it does not contain a backslash. If the
string in the first examples were anything other than '.', say 'a',
the pattern would not match, because the quoted '.' in the pattern
loses its special meaning of matching any single character.
Bracket expressions in regular expressions can be sources of errors
as well, since characters that are normally special in regular
expressions lose their special meanings between brackets. However,
you can use bracket expressions to match special pattern characters
without quoting them, so they are sometimes useful for this
purpose.
Though it might seem like a strange way to write it, the following
pattern will match a '.' in the string:
[[ . =~ [.] ]]
The shell performs any word expansions before passing the pattern
to the regular expression functions, so you can assume that the
shell's quoting takes precedence. As noted above, the regular
expression parser will interpret any unquoted backslashes remaining
in the pattern after shell expansion according to its own rules.
The intention is to avoid making shell programmers quote things
twice as much as possible, so shell quoting should be sufficient to
quote special pattern characters where that's necessary.
The array variable 'BASH_REMATCH' records which parts of the string
matched the pattern. The element of 'BASH_REMATCH' with index 0
contains the portion of the string matching the entire regular
expression. Substrings matched by parenthesized subexpressions
within the regular expression are saved in the remaining
'BASH_REMATCH' indices. The element of 'BASH_REMATCH' with index N
is the portion of the string matching the Nth parenthesized
subexpression.
Expressions may be combined using the following operators, listed
in decreasing order of precedence:
@@ -3046,6 +3105,11 @@ standard.
absolute pathname of the new working directory is written to the
standard output.
If the directory change is successful, 'cd' sets the value of the
'PWD' environment variable to the new directory name, and sets the
'OLDPWD' environment variable to the value of the current working
directory before the change.
The return status is zero if the directory is successfully changed,
non-zero otherwise.
@@ -6503,10 +6567,14 @@ File: bashref.info, Node: Directory Stack Builtins, Up: The Directory Stack
'popd'
popd [-n] [+N | -N]
Removes elements from the directory stack. The elements are
numbered from 0 starting at the first directory listed by 'dirs';
that is, 'popd' is equivalent to 'popd +0'.
When no arguments are given, 'popd' removes the top directory from
the stack and performs a 'cd' to the new top directory. The
elements are numbered from 0 starting at the first directory listed
with 'dirs'; that is, 'popd' is equivalent to 'popd +0'.
the stack and changes to the new top directory.
Arguments, if supplied, have the following meanings:
'-n'
Suppresses the normal change of directory when removing
@@ -6514,17 +6582,32 @@ File: bashref.info, Node: Directory Stack Builtins, Up: The Directory Stack
manipulated.
'+N'
Removes the Nth directory (counting from the left of the list
printed by 'dirs'), starting with zero.
printed by 'dirs'), starting with zero, from the stack.
'-N'
Removes the Nth directory (counting from the right of the list
printed by 'dirs'), starting with zero.
printed by 'dirs'), starting with zero, from the stack.
If the top element of the directory stack is modified, and the '-n'
option was not supplied, 'popd' uses the 'cd' builtin to change to
the directory at the top of the stack. If the 'cd' fails, 'popd'
returns a non-zero value.
Otherwise, 'popd' returns an unsuccessful status if an invalid
option is encountered, the directory stack is empty, or a
non-existent directory stack entry is specified.
If the 'popd' command is successful, a 'dirs' is performed as well,
and the return status is 0.
'pushd'
pushd [-n] [+N | -N | DIR]
Save the current directory on the top of the directory stack and
then 'cd' to DIR. With no arguments, 'pushd' exchanges the top two
directories and makes the new top the current directory.
Adds a directory to the top of the directory stack, or rotates the
stack, making the new top of the stack the current working
directory. With no arguments, 'pushd' exchanges the top two
elements of the directory stack.
Arguments, if supplied, have the following meanings:
'-n'
Suppresses the normal change of directory when rotating or
@@ -6539,9 +6622,20 @@ File: bashref.info, Node: Directory Stack Builtins, Up: The Directory Stack
printed by 'dirs', starting with zero) to the top of the list
by rotating the stack.
'DIR'
Makes DIR be the top of the stack, making it the new current
directory as if it had been supplied as an argument to the
'cd' builtin.
Makes DIR be the top of the stack.
After the stack has been modified, if the '-n' option was not
supplied, 'pushd' uses the 'cd' builtin to change to the directory
at the top of the stack. If the 'cd' fails, 'pushd' returns a
non-zero value.
Otherwise, if no arguments are supplied, 'pushd' returns 0 unless
the directory stack is empty. When rotating the directory stack,
'pushd' returns 0 unless the directory stack is empty or a
non-existent directory stack element is specified.
If the 'pushd' command is successful, a 'dirs' is performed as
well.

File: bashref.info, Node: Controlling the Prompt, Next: The Restricted Shell, Prev: The Directory Stack, Up: Bash Features
@@ -6597,8 +6691,8 @@ which can appear in the prompt variables 'PS0', 'PS1', 'PS2', and 'PS4':
'\V'
The release of Bash, version + patchlevel (e.g., 2.00.0)
'\w'
The current working directory, with '$HOME' abbreviated with a
tilde (uses the '$PROMPT_DIRTRIM' variable).
The value of the 'PWD' shell variable ('$PWD'), with '$HOME'
abbreviated with a tilde (uses the '$PROMPT_DIRTRIM' variable).
'\W'
The basename of '$PWD', with '$HOME' abbreviated with a tilde.
'\!'
@@ -11298,7 +11392,7 @@ D.1 Index of Shell Builtin Commands
* :: Bourne Shell Builtins.
(line 11)
* [: Bourne Shell Builtins.
(line 270)
(line 275)
* alias: Bash Builtins. (line 11)
* bg: Job Control Builtins.
(line 7)
@@ -11317,7 +11411,7 @@ D.1 Index of Shell Builtin Commands
* compopt: Programmable Completion Builtins.
(line 237)
* continue: Bourne Shell Builtins.
(line 85)
(line 90)
* declare: Bash Builtins. (line 151)
* dirs: Directory Stack Builtins.
(line 7)
@@ -11326,21 +11420,21 @@ D.1 Index of Shell Builtin Commands
* echo: Bash Builtins. (line 254)
* enable: Bash Builtins. (line 303)
* eval: Bourne Shell Builtins.
(line 94)
(line 99)
* exec: Bourne Shell Builtins.
(line 102)
(line 107)
* exit: Bourne Shell Builtins.
(line 120)
(line 125)
* export: Bourne Shell Builtins.
(line 127)
(line 132)
* fc: Bash History Builtins.
(line 10)
* fg: Job Control Builtins.
(line 17)
* getopts: Bourne Shell Builtins.
(line 143)
(line 148)
* hash: Bourne Shell Builtins.
(line 187)
(line 192)
* help: Bash Builtins. (line 332)
* history: Bash History Builtins.
(line 46)
@@ -11356,36 +11450,36 @@ D.1 Index of Shell Builtin Commands
(line 35)
* printf: Bash Builtins. (line 426)
* pushd: Directory Stack Builtins.
(line 53)
(line 69)
* pwd: Bourne Shell Builtins.
(line 207)
(line 212)
* read: Bash Builtins. (line 475)
* readarray: Bash Builtins. (line 571)
* readonly: Bourne Shell Builtins.
(line 217)
(line 222)
* return: Bourne Shell Builtins.
(line 236)
(line 241)
* set: The Set Builtin. (line 11)
* shift: Bourne Shell Builtins.
(line 257)
(line 262)
* shopt: The Shopt Builtin. (line 9)
* source: Bash Builtins. (line 580)
* suspend: Job Control Builtins.
(line 113)
* test: Bourne Shell Builtins.
(line 270)
(line 275)
* times: Bourne Shell Builtins.
(line 349)
(line 354)
* trap: Bourne Shell Builtins.
(line 355)
(line 360)
* type: Bash Builtins. (line 585)
* typeset: Bash Builtins. (line 617)
* ulimit: Bash Builtins. (line 623)
* umask: Bourne Shell Builtins.
(line 404)
(line 409)
* unalias: Bash Builtins. (line 729)
* unset: Bourne Shell Builtins.
(line 422)
(line 427)
* wait: Job Control Builtins.
(line 76)
@@ -12054,114 +12148,114 @@ Node: Lists24904
Node: Compound Commands26699
Node: Looping Constructs27711
Node: Conditional Constructs30206
Node: Command Grouping41777
Node: Coprocesses43252
Node: GNU Parallel45915
Node: Shell Functions50216
Node: Shell Parameters57436
Node: Positional Parameters61869
Node: Special Parameters62771
Node: Shell Expansions65995
Node: Brace Expansion68122
Node: Tilde Expansion70847
Node: Shell Parameter Expansion73468
Node: Command Substitution88597
Node: Arithmetic Expansion89952
Node: Process Substitution90884
Node: Word Splitting92004
Node: Filename Expansion93948
Node: Pattern Matching96497
Node: Quote Removal100487
Node: Redirections100782
Node: Executing Commands110356
Node: Simple Command Expansion111026
Node: Command Search and Execution112980
Node: Command Execution Environment115358
Node: Environment118344
Node: Exit Status120007
Node: Signals121679
Node: Shell Scripts123646
Node: Shell Builtin Commands126658
Node: Bourne Shell Builtins128696
Node: Bash Builtins149652
Node: Modifying Shell Behavior179802
Node: The Set Builtin180147
Node: The Shopt Builtin190560
Node: Special Builtins205472
Node: Shell Variables206451
Node: Bourne Shell Variables206888
Node: Bash Variables208992
Node: Bash Features241650
Node: Invoking Bash242663
Node: Bash Startup Files248676
Node: Interactive Shells253779
Node: What is an Interactive Shell?254189
Node: Is this Shell Interactive?254838
Node: Interactive Shell Behavior255653
Node: Bash Conditional Expressions259166
Node: Shell Arithmetic263743
Node: Aliases266687
Node: Arrays269300
Node: The Directory Stack275309
Node: Directory Stack Builtins276093
Node: Controlling the Prompt279061
Node: The Restricted Shell282009
Node: Bash POSIX Mode284603
Node: Shell Compatibility Mode295876
Node: Job Control302532
Node: Job Control Basics302992
Node: Job Control Builtins307994
Node: Job Control Variables313394
Node: Command Line Editing314550
Node: Introduction and Notation316221
Node: Readline Interaction317844
Node: Readline Bare Essentials319035
Node: Readline Movement Commands320818
Node: Readline Killing Commands321778
Node: Readline Arguments323696
Node: Searching324740
Node: Readline Init File326926
Node: Readline Init File Syntax328185
Node: Conditional Init Constructs348723
Node: Sample Init File352919
Node: Bindable Readline Commands356043
Node: Commands For Moving357247
Node: Commands For History359298
Node: Commands For Text364091
Node: Commands For Killing367740
Node: Numeric Arguments370773
Node: Commands For Completion371912
Node: Keyboard Macros376103
Node: Miscellaneous Commands376790
Node: Readline vi Mode382729
Node: Programmable Completion383636
Node: Programmable Completion Builtins391416
Node: A Programmable Completion Example402111
Node: Using History Interactively407358
Node: Bash History Facilities408042
Node: Bash History Builtins411047
Node: History Interaction416055
Node: Event Designators419675
Node: Word Designators421029
Node: Modifiers422789
Node: Installing Bash424600
Node: Basic Installation425737
Node: Compilers and Options428995
Node: Compiling For Multiple Architectures429736
Node: Installation Names431429
Node: Specifying the System Type432247
Node: Sharing Defaults432963
Node: Operation Controls433636
Node: Optional Features434594
Node: Reporting Bugs445394
Node: Major Differences From The Bourne Shell446588
Node: GNU Free Documentation License463438
Node: Indexes488615
Node: Builtin Index489069
Node: Reserved Word Index495896
Node: Variable Index498344
Node: Function Index514241
Node: Concept Index527889
Node: Command Grouping44368
Node: Coprocesses45843
Node: GNU Parallel48506
Node: Shell Functions52807
Node: Shell Parameters60027
Node: Positional Parameters64460
Node: Special Parameters65362
Node: Shell Expansions68586
Node: Brace Expansion70713
Node: Tilde Expansion73438
Node: Shell Parameter Expansion76059
Node: Command Substitution91188
Node: Arithmetic Expansion92543
Node: Process Substitution93475
Node: Word Splitting94595
Node: Filename Expansion96539
Node: Pattern Matching99088
Node: Quote Removal103078
Node: Redirections103373
Node: Executing Commands112947
Node: Simple Command Expansion113617
Node: Command Search and Execution115571
Node: Command Execution Environment117949
Node: Environment120935
Node: Exit Status122598
Node: Signals124270
Node: Shell Scripts126237
Node: Shell Builtin Commands129249
Node: Bourne Shell Builtins131287
Node: Bash Builtins152492
Node: Modifying Shell Behavior182642
Node: The Set Builtin182987
Node: The Shopt Builtin193400
Node: Special Builtins208312
Node: Shell Variables209291
Node: Bourne Shell Variables209728
Node: Bash Variables211832
Node: Bash Features244490
Node: Invoking Bash245503
Node: Bash Startup Files251516
Node: Interactive Shells256619
Node: What is an Interactive Shell?257029
Node: Is this Shell Interactive?257678
Node: Interactive Shell Behavior258493
Node: Bash Conditional Expressions262006
Node: Shell Arithmetic266583
Node: Aliases269527
Node: Arrays272140
Node: The Directory Stack278149
Node: Directory Stack Builtins278933
Node: Controlling the Prompt283119
Node: The Restricted Shell286084
Node: Bash POSIX Mode288678
Node: Shell Compatibility Mode299951
Node: Job Control306607
Node: Job Control Basics307067
Node: Job Control Builtins312069
Node: Job Control Variables317469
Node: Command Line Editing318625
Node: Introduction and Notation320296
Node: Readline Interaction321919
Node: Readline Bare Essentials323110
Node: Readline Movement Commands324893
Node: Readline Killing Commands325853
Node: Readline Arguments327771
Node: Searching328815
Node: Readline Init File331001
Node: Readline Init File Syntax332260
Node: Conditional Init Constructs352798
Node: Sample Init File356994
Node: Bindable Readline Commands360118
Node: Commands For Moving361322
Node: Commands For History363373
Node: Commands For Text368166
Node: Commands For Killing371815
Node: Numeric Arguments374848
Node: Commands For Completion375987
Node: Keyboard Macros380178
Node: Miscellaneous Commands380865
Node: Readline vi Mode386804
Node: Programmable Completion387711
Node: Programmable Completion Builtins395491
Node: A Programmable Completion Example406186
Node: Using History Interactively411433
Node: Bash History Facilities412117
Node: Bash History Builtins415122
Node: History Interaction420130
Node: Event Designators423750
Node: Word Designators425104
Node: Modifiers426864
Node: Installing Bash428675
Node: Basic Installation429812
Node: Compilers and Options433070
Node: Compiling For Multiple Architectures433811
Node: Installation Names435504
Node: Specifying the System Type436322
Node: Sharing Defaults437038
Node: Operation Controls437711
Node: Optional Features438669
Node: Reporting Bugs449469
Node: Major Differences From The Bourne Shell450663
Node: GNU Free Documentation License467513
Node: Indexes492690
Node: Builtin Index493144
Node: Reserved Word Index499971
Node: Variable Index502419
Node: Function Index518316
Node: Concept Index531964

End Tag Table
doc/bashref.texi
+110 -41
View File
@@ -1059,79 +1059,112 @@ is enabled, the match is performed without regard to the case
of alphabetic characters.
The return value is 0 if the string matches (@samp{==}) or does not
match (@samp{!=}) the pattern, and 1 otherwise.
Any part of the pattern may be quoted to force the quoted portion
to be matched as a string.
If you quote any part of the pattern,
using any of the shell's quoting mechanisms,
the quoted portion is matched literally.
This means every character in the quoted portion matches itself,
instead of having any special pattern matching meaning.
An additional binary operator, @samp{=~}, is available, with the same
precedence as @samp{==} and @samp{!=}.
When it is used, the string to the right of the operator is considered
a @sc{posix} extended regular expression and matched accordingly
When you use @samp{=~}, the string to the right of the operator is considered
a @sc{posix} extended regular expression pattern and matched accordingly
(using the @sc{posix} @code{regcomp} and @code{regexec} interfaces
usually described in @i{regex}(3)).
The return value is 0 if the string matches
the pattern, and 1 otherwise.
The return value is 0 if the string matches the pattern, and 1 if it does not.
If the regular expression is syntactically incorrect, the conditional
expression's return value is 2.
expression returns 2.
If the @code{nocasematch} shell option
(see the description of @code{shopt} in @ref{The Shopt Builtin})
is enabled, the match is performed without regard to the case
of alphabetic characters.
Any part of the pattern may be quoted to force the quoted portion
to be matched as a string.
Bracket expressions in regular expressions must be treated carefully,
since normal quoting characters lose their meanings between brackets.
You can quote any part of the pattern
to force the quoted portion to be matched literally
instead of as a regular expression (see above).
If the pattern is stored in a shell variable, quoting the variable
expansion forces the entire pattern to be matched as a string.
expansion forces the entire pattern to be matched literally.
The pattern will match if it matches any part of the string.
Anchor the pattern using the @samp{^} and @samp{$} regular expression
operators to force it to match the entire string.
The array variable @code{BASH_REMATCH} records which parts of the string
matched the pattern.
The element of @code{BASH_REMATCH} with index 0 contains the portion of
the string matching the entire regular expression.
Substrings matched by parenthesized subexpressions within the regular
expression are saved in the remaining @code{BASH_REMATCH} indices.
The element of @code{BASH_REMATCH} with index @var{n} is the portion of the
string matching the @var{n}th parenthesized subexpression.
If you want to force the pattern to match the entire string,
anchor the pattern using the @samp{^} and @samp{$} regular expression
operators.
For example, the following will match a line
(stored in the shell variable @var{line})
(stored in the shell variable @code{line})
if there is a sequence of characters anywhere in the value consisting of
any number, including zero, of
characters in the @code{space} character class,
zero or one instances of @samp{a}, then a @samp{b}:
immediately followed by zero or one instances of @samp{a},
then a @samp{b}:
@example
[[ $line =~ [[:space:]]*(a)?b ]]
@end example
@noindent
That means values like @samp{aab} and @samp{ aaaaaab} will match, as
will a line containing a @samp{b} anywhere in its value.
That means values for @code{line} like
@samp{aab}, @samp{ aaaaaab}, @samp{xaby}, and @samp{ ab}
will all match,
as will a line containing a @samp{b} anywhere in its value.
If you want to match a character that's special to the regular expression
grammar (@samp{^$|[]()\.*+?}), it has to be quoted to remove its special
meaning.
This means that in the pattern @samp{xxx.txt}, the @samp{.} matches any
character in the string (its usual regular expression meaning), but in the
pattern @samp{"xxx.txt"}, it can only match a literal @samp{.}.
Likewise, if you want to include a character in your pattern that has a
special meaning to the regular expression grammar, you must make sure it's
not quoted.
If you want to anchor a pattern at the beginning or end of the string,
for instance, you cannot quote the @samp{^} or @samp{$}
characters using any form of shell quoting.
If you want to match @samp{initial string} at the start of a line,
the following will work:
@example
[[ $line =~ ^"initial string" ]]
@end example
@noindent
but this will not:
@example
[[ $line =~ "^initial string" ]]
@end example
@noindent
because in the second example the @samp{^} is quoted and doesn't have its
usual special meaning.
It is sometimes difficult to specify a regular expression properly
without using quotes, or to keep track of the quoting used by regular
expressions while paying attention to
shell quoting and the shell's quote removal.
Storing the regular expression in a shell variable is often a useful
way to avoid problems with quoting characters that are special to the
shell.
It is sometimes difficult to specify a regular expression literally
without using quotes, or to keep track of the quoting used by regular
expressions while paying attention to the shell's quote removal.
Using a shell variable to store the pattern decreases these problems.
For example, the following is equivalent to the above:
For example, the following is equivalent to the pattern used above:
@example
pattern='[[:space:]]*(a)?b'
[[ $line =~ $pattern ]]
@end example
@noindent
If you want to match a character that's special to the regular expression
grammar, it has to be quoted to remove its special meaning.
This means that in the pattern @samp{xxx.txt}, the @samp{.} matches any
character in the string (its usual regular expression meaning), but in the
pattern @samp{"xxx.txt"} it can only match a literal @samp{.}.
Shell programmers should take special care with backslashes, since backslashes
are used by both the shell and regular expressions to remove the special
meaning from the following character.
Shell programmers should take special care with backslashes, since
backslashes are used by both the shell and regular expressions to remove
the special meaning from the following character.
This means that after the shell's word expansions complete
(@pxref{Shell Expansions}),
any backslashes remaining in parts of the pattern
that were originally not quoted can remove the
special meaning of pattern characters.
If any part of the pattern is quoted, the shell does its best to ensure that
the regular expression treats those remaining backslashes as literal,
if they appeared in a quoted portion.
The following two sets of commands are @emph{not} equivalent:
@example
pattern='\.'
@@ -1145,12 +1178,48 @@ pattern='\.'
@noindent
The first two matches will succeed, but the second two will not, because
in the second two the backslash will be part of the pattern to be matched.
In the first two examples, the backslash removes the special meaning from
In the first two examples, the pattern passed to the regular expression
parser is @samp{\.}. The backslash removes the special meaning from
@samp{.}, so the literal @samp{.} matches.
In the second two examples, the pattern passed to the regular expression
parser has the backslash quoted (e.g., @samp{\\\.}), which will not match
the string, since it does not contain a backslash.
If the string in the first examples were anything other than @samp{.}, say
@samp{a}, the pattern would not match, because the quoted @samp{.} in the
pattern loses its special meaning of matching any single character.
Bracket expressions in regular expressions can be sources of errors as well,
since characters that are normally special in regular expressions
lose their special meanings between brackets.
However, you can use bracket expressions to match special pattern characters
without quoting them, so they are sometimes useful for this purpose.
Though it might seem like a strange way to write it, the following pattern
will match a @samp{.} in the string:
@example
[[ . =~ [.] ]]
@end example
The shell performs any word expansions before passing the pattern
to the regular expression functions,
so you can assume that the shell's quoting takes precedence.
As noted above, the regular expression parser will interpret any
unquoted backslashes remaining in the pattern after shell expansion
according to its own rules.
The intention is to avoid making shell programmers quote things twice
as much as possible, so shell quoting should be sufficient to quote
special pattern characters where that's necessary.
The array variable @code{BASH_REMATCH} records which parts of the string
matched the pattern.
The element of @code{BASH_REMATCH} with index 0 contains the portion of
the string matching the entire regular expression.
Substrings matched by parenthesized subexpressions within the regular
expression are saved in the remaining @code{BASH_REMATCH} indices.
The element of @code{BASH_REMATCH} with index @var{n} is the portion of the
string matching the @var{n}th parenthesized subexpression.
Expressions may be combined using the following operators, listed
in decreasing order of precedence:
execute_cmd.c
+7 -2
View File
@@ -5585,17 +5585,22 @@ execute_disk_command (words, redirects, command_line, pipe_in, pipe_out,
/* reset shell_pgrp to pipeline_pgrp here for word expansions performed
by the redirections here? */
if (redirects && (do_redirections (redirects, RX_ACTIVE) != 0))
{
#if defined (PROCESS_SUBSTITUTION)
/* Try to remove named pipes that may have been created as the
result of redirections. */
unlink_fifo_list ();
unlink_all_fifos ();
#endif /* PROCESS_SUBSTITUTION */
exit (EXECUTION_FAILURE);
}
#if defined (PROCESS_SUBSTITUTION) && !defined (HAVE_DEV_FD)
/* This should only contain FIFOs created as part of redirection
expansion. */
unlink_all_fifos ();
#endif
if (async)
interactive = old_interactive;