Bash-5.2 official patch 2
BASH PATCH REPORT = Bash-Release: 5.2 Patch-ID: bash52-002 Bug-Reported-by:Kan-Ru Chen Bug-Reference-ID: Bug-Reference-URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021109 Bug-Description: Starting bash with an invalid locale specification for LC_ALL/LANG/LC_CTYPE can cause the shell to crash. Patch (apply with `patch -p0'): *** ../bash-5.2-patched/lib/readline/nls.c 2022-08-15 09:38:51.0 -0400 --- lib/readline/nls.c 2022-10-05 09:23:22.0 -0400 *** *** 142,145 --- 142,149 lspec = ""; ret = setlocale (LC_CTYPE, lspec); /* ok, since it does not change locale */ + if (ret == 0 || *ret == 0) + ret = setlocale (LC_CTYPE, (char *)NULL); + if (ret == 0 || *ret == 0) + ret = RL_DEFAULT_LOCALE; #else ret = (lspec == 0 || *lspec == 0) ? RL_DEFAULT_LOCALE : lspec; *** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400 --- patchlevel.h2020-10-01 11:01:28.0 -0400 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 1 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 2 #endif /* _PATCHLEVEL_H_ */ -- ``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 official patch 1
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-001
Bug-Reported-by:Emanuele Torre
Bug-Reference-ID:
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00060.html
Bug-Description:
Expanding unset arrays in an arithmetic context can cause a segmentation fault.
Patch (apply with `patch -p0'):
*** ../bash-5.2/subst.c 2022-08-31 17:36:46.0 -0400
--- subst.c 2022-09-30 09:12:05.0 -0400
***
*** 10858,10862
t = expand_subscript_string (exp, quoted & ~(Q_ARITH|Q_DOUBLE_QUOTES));
free (exp);
! exp = sh_backslash_quote (t, abstab, 0);
free (t);
--- 10858,10862
t = expand_subscript_string (exp, quoted & ~(Q_ARITH|Q_DOUBLE_QUOTES));
free (exp);
! exp = t ? sh_backslash_quote (t, abstab, 0) : savestring ("");
free (t);
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 0
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 1
#endif /* _PATCHLEVEL_H_ */
--
``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: declare -F incorrect line number
On 10/2/22 4:51 AM, Daniel Castro wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: declare -F yields the wrong line number for a function that has nested functions declared within. Instead it gives the line number of the last nested function. Thanks for the report. I'll take a look, but I have a question. Why are you declaring functions inside functions? Are you trying to do some kind of conditional definition? 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/
RE: declare -F incorrect line number
In this case I’m not doing anything too fancy: my use case is I have a main project script where I declare functions that can get executed independently with some prefix: e.g. ``x.build()``, ``x.test()`` so I can call ``myscript test`` or ``myscript build`` by parsing all x.* functions, and sometimes I have functions within them just for clarity since they’re just some abstraction for that particular function logic. I parse these x function's comments as well to show in ``--help`` and therefore happened to notice the bug. The workaround for me is to simply move them outside the top level function, but I don't know if it would get in the way for some people doing more convoluted stuff with functions. From: [1]Chet Ramey Sent: Wednesday, 5 October 2022 20:22 To: [2]Daniel Castro; [3]bug-bash@gnu.org Cc: [4]chet.ra...@case.edu Subject: Re: declare -F incorrect line number On 10/2/22 4:51 AM, Daniel Castro wrote: > Bash Version: 5.0 > > Patch Level: 17 > > Release Status: release > > > Description: > > declare -F yields the wrong line number for a function that has > nested functions declared within. Instead it gives the line number of > the last nested function. Thanks for the report. I'll take a look, but I have a question. Why are you declaring functions inside functions? Are you trying to do some kind of conditional definition? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu http://tiswww.cwru.edu/~chet/ References 1. mailto:chet.ra...@case.edu 2. mailto:danicc...@gmail.com 3. mailto:bug-bash@gnu.org 4. mailto:chet.ra...@case.edu
Re: declare -F incorrect line number
On 10/5/22 3:32 PM, Daniel Castro wrote: In this case I’m not doing anything too fancy: my use case is I have a main project script where I declare functions that can get executed independently with some prefix: e.g. ``x.build()``, ``x.test()`` so I can call ``myscript test`` or ``myscript build`` by parsing all x.* functions, and sometimes I have functions within them just for clarity since they’re just some abstraction for that particular function logic. I parse these x function's comments as well to show in ``--help`` and therefore happened to notice the bug. The workaround for me is to simply move them outside the top level function, but I don't know if it would get in the way for some people doing more convoluted stuff with functions. That's why I was asking -- there's no such thing as a local function, but I can see wanting to declare a set of functions only if the `main' function gets declared as an abstraction technique. Other than that, there's no advantage. 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/
Re: declare -F incorrect line number
Date:Wed, 5 Oct 2022 15:36:55 -0400
From:Chet Ramey
Message-ID: <3d89acac-4c0a-64c9-e22c-1a3ca6860...@case.edu>
| Other than that, there's no advantage.
There can be. I have, on occasion (not in bash - I don't
write bash scripts) had a need to redefine one of the standard
commands, while executing a particular function (which calls other
more standard functions which run the command) - and define the
same command differently when running a different function, which
runs the same standard functions running the command, but in a
different way.
Kind of like
f1() {
diff() { command diff -u "$@"; }
dostuff
unset -f diff
}
f2() {
diff() { command diff -iw -c "$@"; }
dostuff
unset -f diff
}
where dostuff() does what ever is needed to make "newversion",
and then, somewhere does one (or more) of something like
diff origfile newversion
"dostuff" can also just be run to get the default diff format.
or something like that. Real examples tend to be far more complicated
(this simple case could be done just by having DIFFARGS or something, but
that would mean modifying dostuff() to use that as diff $DIFFARGS )
kre
