commit bash-20200520 snapshot

This commit is contained in:
Chet Ramey
2020-05-27 09:00:49 -04:00
parent e76c732799
commit ce1a3c07c4
102 changed files with 29297 additions and 18340 deletions
+190 -70
View File
@@ -1064,8 +1064,8 @@ to be matched as a string.
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
(using the @sc{POSIX} @code{regcomp} and @code{regexec} interfaces
a @sc{posix} extended regular expression 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.
@@ -4790,7 +4790,7 @@ allow this value to be set).
The pipe buffer size.
@item -q
The maximum number of bytes in POSIX message queues.
The maximum number of bytes in @sc{posix} message queues.
@item -r
The maximum real-time scheduling priority.
@@ -5270,61 +5270,14 @@ This option is enabled by default, but only has an effect if command
history is enabled (@pxref{Bash History Facilities}).
@item compat31
If set, Bash
changes its behavior to that of version 3.1 with respect to quoted
arguments to the conditional command's @samp{=~} operator
and with respect to locale-specific
string comparison when using the @code{[[}
conditional command's @samp{<} and @samp{>} operators.
Bash versions prior to bash-4.1 use ASCII collation and strcmp(3);
bash-4.1 and later use the current locale's collation sequence and strcoll(3).
@item compat32
If set, Bash
changes its behavior to that of version 3.2 with respect to locale-specific
string comparison when using the @code{[[}
conditional command's @samp{<} and @samp{>} operators (see previous item)
and the effect of interrupting a command list.
Bash versions 3.2 and earlier continue with the next command in the list
after one terminates due to an interrupt.
@item compat40
If set, Bash
changes its behavior to that of version 4.0 with respect to locale-specific
string comparison when using the @code{[[}
conditional command's @samp{<} and @samp{>} operators (see description
of @code{compat31})
and the effect of interrupting a command list.
Bash versions 4.0 and later interrupt the list as if the shell received the
interrupt; previous versions continue with the next command in the list.
@item compat41
If set, Bash, when in @sc{posix} mode, treats a single quote in a double-quoted
parameter expansion as a special character. The single quotes must match
(an even number) and the characters between the single quotes are considered
quoted. This is the behavior of @sc{posix} mode through version 4.1.
The default Bash behavior remains as in previous versions.
@item compat42
If set, Bash
does not process the replacement string in the pattern substitution word
expansion using quote removal.
@item compat43
If set, Bash
does not print a warning message if an attempt is made to use a quoted compound
array assignment as an argument to @code{declare},
makes word expansion errors
non-fatal errors that cause the current command to fail (the default behavior is
to make them fatal errors that cause the shell to exit),
and does not reset the
loop state when a shell function is executed (this allows @code{break} or
@code{continue} in a shell function to affect loops in the caller's context).
@item compat44
If set, Bash
saves the positional parameters to BASH_ARGV and BASH_ARGC before they are
used, regardless of whether or not extended debugging mode is enabled.
@itemx compat32
@itemx compat40
@itemx compat41
@itemx compat42
@itemx compat43
@itemx compat44
These control aspects of the shell's compatibility mode
(@pxref{Shell Compatibility Mode}).
@item complete_fullquote
If set, Bash
@@ -5807,18 +5760,20 @@ subsequently reset.
@item BASH_COMPAT
The value is used to set the shell's compatibility level.
@xref{The Shopt Builtin}, for a description of the various compatibility
levels and their effects.
@xref{Shell Compatibility Mode}, for a description of the various
compatibility levels and their effects.
The value may be a decimal number (e.g., 4.2) or an integer (e.g., 42)
corresponding to the desired compatibility level.
If @code{BASH_COMPAT} is unset or set to the empty string, the compatibility
If @env{BASH_COMPAT} is unset or set to the empty string, the compatibility
level is set to the default for the current version.
If @code{BASH_COMPAT} is set to a value that is not one of the valid
If @env{BASH_COMPAT} is set to a value that is not one of the valid
compatibility levels, the shell prints an error message and sets the
compatibility level to the default for the current version.
The valid compatibility levels correspond to the compatibility options
accepted by the @code{shopt} builtin described above (for example,
@var{compat42} means that 4.2 and 42 are valid values).
The valid values correspond to the compatibility levels
described below (@pxref{Shell Compatibility Mode}).
For example, 4.2 and 42 are valid values that correspond
to the @code{compat42} @code{shopt} option
and set the compatibility level to 42.
The current version is also a valid value.
@item BASH_ENV
@@ -6519,6 +6474,8 @@ This chapter describes features unique to Bash.
* The Restricted Shell:: A more controlled mode of shell execution.
* Bash POSIX Mode:: Making Bash behave more closely to what
the POSIX standard specifies.
* Shell Compatibility Mode:: How Bash supports behavior that was present
in earlier versions and has changed.
@end menu
@node Invoking Bash
@@ -7891,11 +7848,6 @@ double-quoted.
Assignment statements preceding @sc{posix} special builtins
persist in the shell environment after the builtin completes.
@item
Assignment statements preceding shell function calls persist in the
shell environment after the function returns, as if a @sc{posix}
special builtin command had been executed.
@item
The @code{command} builtin does not prevent builtins that take assignment
statements as arguments from expanding them as assignment statements;
@@ -7931,6 +7883,10 @@ is a valid signal number. If users want to reset the handler for a given
signal to the original disposition, they should use @samp{-} as the
first argument.
@item
@code{trap -p} displays signals whose dispositions are set to SIG_DFL and
those that were ignored when the shell started.
@item
The @code{.} and @code{source} builtins do not search the current directory
for the filename argument if it is not found by searching @env{PATH}.
@@ -8045,6 +8001,170 @@ Bash can be configured to be @sc{posix}-conformant by default, by specifying
the @option{--enable-strict-posix-default} to @code{configure} when building
(@pxref{Optional Features}).
@node Shell Compatibility Mode
@section Shell Compatibility Mode
@cindex Compatibility Level
@cindex Compatibility Mode
Bash-4.0 introduced the concept of a `shell compatibility level', specified
as a set of options to the shopt builtin
(@code{compat31},
@code{compat32},
@code{compat40},
@code{compat41},
and so on).
There is only one current
compatibility level -- each option is mutually exclusive.
The compatibility level is intended to allow users to select behavior
from previous versions that is incompatible with newer versions
while they migrate scripts to use current features and
behavior. It's intended to be a temporary solution.
This section does not mention behavior that is standard for a particular
version (e.g., setting @code{compat32} means that quoting the rhs of the regexp
matching operator quotes special regexp characters in the word, which is
default behavior in bash-3.2 and above).
If a user enables, say, @code{compat32}, it may affect the behavior of other
compatibility levels up to and including the current compatibility level.
The idea is that each compatibility level controls behavior that changed
in that version of Bash,
but that behavior may have been present in earlier versions.
For instance, the change to use locale-based comparisons with the @code{[[}
command came in bash-4.1, and earlier versions used ASCII-based comparisons,
so enabling @code{compat32} will enable ASCII-based comparisons as well.
That granularity may not be sufficient for
all uses, and as a result users should employ compatibility levels carefully.
Read the documentation for a particular feature to find out the
current behavior.
Bash-4.3 introduced a new shell variable: @env{BASH_COMPAT}.
The value assigned
to this variable (a decimal version number like 4.2, or an integer
corresponding to the @code{compat}@var{NN} option, like 42) determines the
compatibility level.
Starting with bash-4.4, Bash has begun deprecating older compatibility
levels.
Eventually, the options will be removed in favor of @env{BASH_COMPAT}.
Bash-5.0 is the final version for which there will be an individual shopt
option for the previous version. Users should use @env{BASH_COMPAT}
on bash-5.0 and later versions.
The following table describes the behavior changes controlled by each
compatibility level setting.
The @code{compat}@var{NN} tag is used as shorthand for setting the
compatibility level
to @var{NN} using one of the following mechanisms.
For versions prior to bash-5.0, the compatibility level may be set using
the corresponding @code{compat}@var{NN} shopt option.
For bash-4.3 and later versions, the @env{BASH_COMPAT} variable is preferred,
and it is required for bash-5.1 and later versions.
@table @code
@item compat31
@itemize @bullet
@item
quoting the rhs of the @code{[[} command's regexp matching operator (=~)
has no special effect
@end itemize
@item compat32
@itemize @bullet
@item
interrupting a command list such as "a ; b ; c" causes the execution
of the next command in the list (in bash-4.0 and later versions,
the shell acts as if it received the interrupt, so
interrupting one command in a list aborts the execution of the
entire list)
@end itemize
@item compat40
@itemize @bullet
@item
the @samp{<} and @samp{>} operators to the @code{[[} command do not
consider the current locale when comparing strings; they use ASCII
ordering.
Bash versions prior to bash-4.1 use ASCII collation and strcmp(3);
bash-4.1 and later use the current locale's collation sequence and
strcoll(3).
@end itemize
@item compat41
@itemize @bullet
@item
in posix mode, @code{time} may be followed by options and still be
recognized as a reserved word (this is @sc{posix} interpretation 267)
@item
in posix mode, the parser requires that an even number of single
quotes occur in the @var{word} portion of a double-quoted $@{@dots{}@}
parameter expansion and treats them specially, so that characters within
the single quotes are considered quoted
(this is @sc{posix} interpretation 221)
@end itemize
@item compat42
@itemize @bullet
@item
the replacement string in double-quoted pattern substitution does not
undergo quote removal, as it does in versions after bash-4.2
@item
in posix mode, single quotes are considered special when expanding
the @var{word} portion of a double-quoted $@{@dots{}@} parameter expansion
and can be used to quote a closing brace or other special character
(this is part of @sc{posix} interpretation 221);
in later versions, single quotes
are not special within double-quoted word expansions
@end itemize
@item compat43
@itemize @bullet
@item
the shell does not print a warning message if an attempt is made to
use a quoted compound assignment as an argument to declare
(declare -a foo='(1 2)'). Later versions warn that this usage is
deprecated
@item
word expansion errors are considered non-fatal errors that cause the
current command to fail, even in posix mode
(the default behavior is to make them fatal errors that cause the shell
to exit)
@item
when executing a shell function, the loop state (while/until/etc.)
is not reset, so @code{break} or @code{continue} in that function will break
or continue loops in the calling context. Bash-4.4 and later reset
the loop state to prevent this
@end itemize
@item compat44
@itemize @bullet
@item
the shell sets up the values used by @env{BASH_ARGV} and @env{BASH_ARGC}
so they can expand to the shell's positional parameters even if extended
debugging mode is not enabled
@item
a subshell inherits loops from its parent context, so @code{break}
or @code{continue} will cause the subshell to exit.
Bash-5.0 and later reset the loop state to prevent the exit
@item
variable assignments preceding builtins like @code{export} and @code{readonly}
that set attributes continue to affect variables with the same
name in the calling environment even if the shell is not in posix
mode
@end itemize
@item compat50 (set using BASH_COMPAT)
@itemize @bullet
@item
Bash-5.1 changed the way @code{$RANDOM} is generated to introduce slightly
more randomness. If the shell compatibility level is set to 50 or
lower, it reverts to the method from bash-5.0 and previous versions,
so seeding the random number generator by assigning a value to
@env{RANDOM} will produce the same sequence as in bash-5.0
@end itemize
@end table
@node Job Control
@chapter Job Control