Re: unset does not remove functions like a[b] unless -f is specified
2023年2月7日(火) 0:59 Koichi Murase : > By the way, I got a reply from the chair, Andrew, yesterday and could > get my account in the Austing Group Issue Tracker. I'll later submit > an issue about the implementation extension of function names with > slashes. Sorry for the delay about an issue in Austin Group Issue Tracker. I haven't submitted it yet. I'll try to find time this weekend. P.S. The history in [1] is also interesting. Thanks. [1] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg00109.html
Re: Bash 5.2 breaks our Arch Linux devtools
2023年2月16日(木) 0:03 Tobias Powalowski via Bug reports for the GNU
Bourne Again SHell :
> Description:
> latest 5.2.x seems to have introduced a change in shopt extglob:
> https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133
> I'm not sure if my proposed fix for this is correct or if this is just a
> bug in bash 5.2.x not checking the function for shopt first before bailing
> out.
Let me first explain the background. As others are pointing out, there
are no changes about `shopt extglob'. The `shopt extglob' setting is
referenced twice, in the parsing phase and in the execution phase. The
`shopt extglob' should be turned on for both phases. So, if you have
an extglob in shell functions, you need to turn on `extglob' outside
the function to make sure that the function is parsed with `extglob'
being turned on.
Then, let us discuss the main issue. The difference between Bash 5.2
and 5.1 that you observe in the reported case is related to the change
of the parsing point of the content of the process substitution In
Bash 5.1 and below, the content of the process substitution hasn't
been actually parsed until execution, so it was somehow equivalent to
mapfile -t packages < <(eval 'printf "%s\n"
"something/something".pkg.tar?(.!(sig|.*))')
>From Bash 5.2, we started to fully parse the content of the process
substitution in the normal parsing phase to better handle nested (),
{}, etc. and also to detect the syntax problem earlier. This means
that Bash 5.2 became stricter than 5.1, and an existing problem with
the script, which was hidden by the incomplete parsing of process
substitutions, was revealed this time.
> Fix:
>
> Putting shopt options outside the function, but is this the wanted
> behaviour?
Yes, that is the expected usage.
Re: Bash 5.2 breaks our Arch Linux devtools
On Wed, 15 Feb 2023 at 23:29, Tobias Powalowski via Bug reports for the GNU
Bourne Again SHell wrote:
> Hi,
> latest 5.2.x seems to have introduced a change in shopt extglob:
> https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133
> I'm not sure if my proposed fix for this is correct or if this is just a
> bug in bash 5.2.x not checking the function for shopt first before bailing
> out.
> Repeat-By:
> Sample code from our gitlab:
> % bash <<'EOF'
> function x() {
> shopt -s extglob
> mapfile -t packages < <(
> printf "%s\n"
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*))
> )
> shopt -u extglob
> }
> x
> EOF
>
> Results in:
>
> bash: line 3: syntax error near unexpected token `('
>
> bash: line 3: `mapfile -t packages < <(printf "%s\n"
>
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))'
>
>
> Fix:
>
> Putting shopt options outside the function, but is this the wanted
> behaviour?
> Thanks for clarification,
> greetings
> tpowa
> --
>
That's not a change in 5.2, as extglob has always worked that way. However
what might have changed is whether extglob was already enabled elsewhere in
your script, or acquired from a setting in the environment.
As others have noted, when the “shopt -s extglob” command is executed, it
changes how subsequent commands are parsed, and since compound commands are
parsed in their entirety before they begin executing, changes to parser
settings made by commands inside a compound command cannot have any
influence on how any part of the compound command itself is parsed.
With a function the execution is further split into two steps: after a
function definition has been parsed, the definition must be executed (to
register the function name), and then when the function name is invoked
(from elsewhere in the script), the body of the function is executed. This
3rd step is clearly far too late to affect the first step.
Given that the parser mode is global, I would strongly recommend putting
shopt -s extglob right at the start of the script after the #!/bin/bash
line, along with other commands that can affect parsing, such as shopt -s
compat*XX*, shopt -s expand_aliases, set -o braceexpand, or set -o onecmd.
Simply putting «shopt -u extglob» after your function isn't right either,
since the remainder of the script might actually need it turned on, and
turning it off would break it.
There's no good reason to turn off extglob if you're writing a new script,
as it only affects the validity of some very weird corner cases.
# Without extglob this is a function definition;
# with extglob it's an empty glob followed by some args, followed by the
«}» at the start of the next command.
@() { echo In @ func ; }
-Martin
PS: consider
make_toggle() {
if (($#))
then toggle() { echo "It's On" ; make_toggle ; }
else toggle() { echo "It's Off" ; make_toggle -; }
fi
}
# toggle does not exist here
def_toggle
# toggle now exists
Re: [PATCH] aclocal.m4: fix -Wimplicit-function-declaration in dup2 check
> On 2 Feb 2023, at 05:46, Sam James wrote:
>
> dup2 requires a include. Fixes the following when diffing
> config.log
> when testing with a stricter compiler:
> ```
> -warning: call to undeclared function 'dup2'; ISO C99 and later do not
> support implicit function declarations [-Wimplicit-function-declaration]
> +error: call to undeclared function 'dup2'; ISO C99 and later do not support
> implicit function declarations [-Wimplicit-function-declaration]
> ```
> ---
> aclocal.m4 | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/aclocal.m4 b/aclocal.m4
> index cc97bd4b..25e20fc2 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -238,6 +238,9 @@ AC_CACHE_VAL(bash_cv_dup2_broken,
> #include
> #include
> #include
> +#ifdef HAVE_UNISTD_H
> +#include
> +#endif
> int
> main()
> {
> --
> 2.39.1
>
>
ping - this should be trivial and fixes some real issues Gentoo and Fedora have
hit when
doing modern C porting (https://wiki.gentoo.org/wiki/Modern_C_porting,
https://fedoraproject.org/wiki/Changes/PortingToModernC).
Best,
sam
signature.asc
Description: Message signed with OpenPGP
Re: Defining variable as local -r defines variable outside the function in some cases
Date:Wed, 15 Feb 2023 11:57:45 -0500
From:Chet Ramey
Message-ID: <8295e33a-da67-676c-66cb-9593871ce...@case.edu>
| However, it might be time to change this again, since the ultimate
| resolution of issue 654 resulted in POSIX removing the special handling of
| temporary variable assignments preceding function calls (it's all
| completely unspecified in the upcoming revision).
That's because functions and commands should look the same to the code
that calls them, if one does
VAR=foo cmd ...
it should not suddenly behave differently if someone later decides
to make a function
cmd() { command cmd -opt "$@"; }
What happens to VAR should be the same in both cases. Nothing else
makes any sense (the original description for what happened for
functions was just because of the stupid buggy ksh implementation of
them, which didn't do this the only rational way).
For now it needs to be unspecified what happens, because shells are
not yet all rational (some, like bash, actually did what POSIX said
should be done, which is fine when it makes sense, but not otherwise)
so applications cannot yet depend upon one behaviour or the other.
One hopes that all shells will eventually adopt rational behaviour
for this, and a later revision of the standard can reflect that.
kre
ps: this is a very similar issue/rationale as that for the function
name syntax issue discussed here not all that long ago. functions
are commands (when invoked, not the definition) and should be treated in
as similar way as possible to any other command (builtin or in the
filesystem) as possible. The differences we have are just because of
poor implementation choices in the early days.
Re: [PATCH] Add missing parenthesis to tputs declaration in readline's tcap.h
On 2/15/23 2:35 PM, Eduardo A. Bustamante López wrote: Signed-off-by: Eduardo A. Bustamante López Thanks for the report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
[PATCH] Add missing parenthesis to tputs declaration in readline's tcap.h
Signed-off-by: Eduardo A. Bustamante López --- lib/readline/tcap.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/readline/tcap.h b/lib/readline/tcap.h index 1121061b..a9c6322a 100644 --- a/lib/readline/tcap.h +++ b/lib/readline/tcap.h @@ -51,7 +51,7 @@ extern int tgetflag PARAMS((const char *)); extern int tgetnum PARAMS((const char *)); extern char *tgetstr PARAMS((const char *, char **)); -extern int tputs PARAMS((const char *, int, int (*)(int)); +extern int tputs PARAMS((const char *, int, int (*)(int))); extern char *tgoto PARAMS((const char *, int, int)); -- 2.39.1
Re: Defining variable as local -r defines variable outside the function in some cases
On 2/13/23 10:33 AM, Voldemar Lazarev via Bug reports for the GNU Bourne
Again SHell wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
When a function has a variable (e.g. "X") defined as local and read-only ("local -r") and the
function is called with variable of same name ("X") specified before function name (see the
"Repeat-By" section), the variable becomes defined outside the function.
This has kind of a circuitous history. There always needed to be code to
propagate temporary environment variables supplied to function invocations
back to the previous scope in posix mode, since POSIX required that for
years and years. The variables were exported during function execution to
satisfy the "available to the function and its children" semantics.
As part of an effort to increase implementation compatibility in order to
standardize local variables, I changed bash so that local variables and the
temporary environment share the same namespace, so changes to a local
variable in a function that has the same name as a variable in the
temporary environment are reflected to that function's descendents. This
discussion among shell developers happened in late 2001.
(We could never agree on the dynamic/static scoping issue, so that stalled
the standardization effort, and people are still arguing about that today.)
This came in back in January, 2002 and first appeared in bash-2.05b, but
still only in posix mode.
Finally, we get to April, 2013. The "recommended changes" part of
https://www.austingroupbugs.net/view.php?id=654
says:
"For issue 8, if implementors agree, I suggest something like this:
[...]
- Exported: The temporary variable binding has the export attribute
set (until cleared by the function or special built-in utility, if
it chooses to do so).
- Modification makes the binding persist: Any modification to the
variable binding (setting the export attribute even if it is
already set, clearing the export attribute even if it is already
clear, setting the readonly attribute even if it is already set,
setting the value even if it is already set to the same value,
unsetting the variable even if it is already unset) by a function
or special built-in utility causes the binding (with whatever
attributes it has after modification) to persist after the
function or special built-in utility returns."
So the attribute changes get propagated back to the previous scope, but
this doesn't consider local variables, since POSIX doesn't consider local
variables. However, unifying the local variable namespace and the
temporary environment means you end up operating on the same variable.
The current bash behavior (dating from bash-4.3 in 2013) is compatible with
ksh93. However, it might be time to change this again, since the ultimate
resolution of issue 654 resulted in POSIX removing the special handling of
temporary variable assignments preceding function calls (it's all
completely unspecified in the upcoming revision).
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash 5.2 breaks our Arch Linux devtools
On Wed, Feb 15, 2023 at 05:35:10PM +0100, Mike Jonkmans wrote:
> I once had that same issue:
> https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00013.html
>
> Conclusion: the shopt is not yet working until the function has been run.
> (or after the line has been parsed).
Yes. This is not a change in bash 5.2. It would break in any version
of bash.
unicorn:~$ bash-2.05b -c 'x() { shopt -s extglob; echo *.pd@(f|qux); }'
bash-2.05b: -c: line 1: syntax error near unexpected token `('
bash-2.05b: -c: line 1: `x() { shopt -s extglob; echo *.pd@(f|qux); }'
The extglob shopt changes how bash parses commands as it reads them, so
it has to be in effect *before* bash reads a command which contains an
extended glob.
This means you can't turn it on in the middle of a compound command
(such as a function definition, a while loop, and if/then/fi, etc.).
You have to enable it before bash begins reading and parsing the compound
command.
I advise putting it as close to the top of the script as you can.
Re: Bash 5.2 breaks our Arch Linux devtools
On Wed, Feb 15, 2023, 5:36 PM Mike Jonkmans wrote:
> On Wed, Feb 15, 2023 at 02:29:29PM +0100, Tobias Powalowski via Bug
> reports for the GNU Bourne Again SHell wrote:
>
> I once had that same issue:
> https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00013.html
>
> Conclusion: the shopt is not yet working until the function has been run.
> (or after the line has been parsed).
>
same rule for aliases ..
>
> > ,,,
> > % bash <<'EOF'
> >
> > function x() {shopt -s extglobmapfile -t packages < <(printf "%s\n"
> >
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))shopt
> > -u extglob}xEOFResults in:
> >
> > bash: line 3: syntax error near unexpected token `('
> >
> > bash: line 3: `mapfile -t packages < <(printf "%s\n"
> >
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))'
> >
> > Putting shopt options outside the function, but is this the wanted
> > behaviour?
> > ...
> > Tobias Powalowski
>
> --
> Regards, Mike Jonkmans
>
>
Re: Bash 5.2 breaks our Arch Linux devtools
On Wed, Feb 15, 2023 at 02:29:29PM +0100, Tobias Powalowski via Bug reports for
the GNU Bourne Again SHell wrote:
I once had that same issue:
https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00013.html
Conclusion: the shopt is not yet working until the function has been run.
(or after the line has been parsed).
> ,,,
> % bash <<'EOF'
>
> function x() {shopt -s extglobmapfile -t packages < <(printf "%s\n"
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))shopt
> -u extglob}xEOFResults in:
>
> bash: line 3: syntax error near unexpected token `('
>
> bash: line 3: `mapfile -t packages < <(printf "%s\n"
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))'
>
> Putting shopt options outside the function, but is this the wanted
> behaviour?
> ...
> Tobias Powalowski
--
Regards, Mike Jonkmans
Re: "builtin jobs" does not output to stdout.
On 2/14/23 7:09 PM, Koichi Murase wrote: I still don't think `builtin jobs' is equivalent to `jobs' because `jobs' can pick up a shell function. You're right; they're not equivalent. `builtin' guarantees you'll execute the builtin instead of any function replacement. I wish POSIX had picked it up instead of inventing `command'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash 5.2 breaks our Arch Linux devtools
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat
-Werror=format-security -fstack-clash-protection -fcf-protection -g
-ffile-prefix-map=/build/bash/src=/usr/src/debug/bash -flto=auto
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux T-POWA-LX 6.1.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 14
Feb 2023 22:08:08 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Hi,
latest 5.2.x seems to have introduced a change in shopt extglob:
https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133
I'm not sure if my proposed fix for this is correct or if this is just a
bug in bash 5.2.x not checking the function for shopt first before bailing
out.
Repeat-By:
Sample code from our gitlab:
% bash <<'EOF'
function x() {shopt -s extglobmapfile -t packages < <(printf "%s\n"
"dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))shopt
-u extglob}xEOFResults in:
bash: line 3: syntax error near unexpected token `('
bash: line 3: `mapfile -t packages < <(printf "%s\n"
"dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))'
Fix:
Putting shopt options outside the function, but is this the wanted
behaviour?
Thanks for clarification,
greetings
tpowa
--
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org
Archboot Developer
https://bit.ly/archboot
St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de
