Local variable can not unset within shell functions
Hi,
I've a report that with later bash the following which works in bash-4.2
x () {
local x=y
declare -p x
echo $x
unset x
declare -p x
echo $x
}
with
linux-40cm:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
linux-40cm:~ # x
declare -- x="y"
y
-bash: declare: x: not found
but with bash-5.X the reporter sees (and complains)
sl15sp5:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
sl15sp5:~ # x
declare -- x="y"
y
declare -- x
... for global variables it works as expected.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: [bug-bash] Bash-5.2 Patch 22
On 2024/01/16 09:27:19 -0500, Chet Ramey wrote: > On 1/16/24 4:00 AM, Dr. Werner Fink wrote: > > > what is with the readline82-008, readline82-009, and readline82-010 > > patches? > > What about them? Should those be part also of trhe bash52 patches as well? -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: [bug-bash] Bash-5.2 Patch 22
On 2024/01/14 13:34:06 -0500, Chet Ramey wrote:
>BASH PATCH REPORT
>=
>
> Bash-Release: 5.2
> Patch-ID: bash52-022
>
> Bug-Reported-by: srobert...@peratonlabs.com
> Bug-Reference-ID:
> Bug-Reference-URL:
> https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00049.html
>
> Bug-Description:
>
> It's possible for readline to try to zero out a line that's not null-
> terminated, leading to a memory fault.
>
> Patch (apply with `patch -p0'):
>
> *** ../bash-5.2-patched/lib/readline/display.c2022-04-05
> 10:47:31.0 -0400
> --- lib/readline/display.c2022-12-13 13:11:22.0 -0500
> ***
> *** 2684,2692
>
> if (visible_line)
> ! {
> ! temp = visible_line;
> ! while (*temp)
> ! *temp++ = '\0';
> ! }
> rl_on_new_line ();
> forced_display++;
> --- 2735,2740
>
> if (visible_line)
> ! memset (visible_line, 0, line_size);
> !
> rl_on_new_line ();
> forced_display++;
>
> *** ../bash-5.2/patchlevel.h 2020-06-22 14:51:03.0 -0400
> --- patchlevel.h 2020-10-01 11:01:28.0 -0400
> ***
> *** 26,30
> looks for to find the patch level (for the sccs version string). */
>
> ! #define PATCHLEVEL 21
>
> #endif /* _PATCHLEVEL_H_ */
> --- 26,30
> looks for to find the patch level (for the sccs version string). */
>
> ! #define PATCHLEVEL 22
>
> #endif /* _PATCHLEVEL_H_ */
>
Hi,
what is with the readline82-008, readline82-009, and readline82-010
patches?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: [bug-bash] segfault in for(()) loop
On 2023/07/24 13:16:23 -0400, Chet Ramey wrote: > On 7/24/23 11:58 AM, vc--- via Bug reports for the GNU Bourne Again SHell > wrote: > > > Bash Version: 5.2 > > Patch Level: 15 > > Release Status: release > > > > Description: > > Segmentation fault in 'for ((...))' loop > > > > Repeat-By: > > z='';for((;$z;));do echo;done > > without spaces in ;$z; > > in bash 5.1.4 -- works ok, in bash 5.2.15 -- segmentation fault > > Thanks for the report. This was fixed several months ago. OK ... last official patch for 5.2 is still bash52-015 :) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Extrem memory consumption during unicode test with alt-array implementation
Hi, Just to mention due to the extrem memory consumption during unicode tests with enabled altenative array implementation the speed win is more then equalised. That is the build system becomes unusable ps aux | grep -E 'USER|^399' USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND [...] 399 6641 24.9 87.4 14690520 7073924 pts/0 R+ 13:37 0:18 /home/abuild/rpmbuild/BUILD/bash-5.2/bash ./unicode1.sub Now building without --enable-alt-array-implementation Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 2020/10/28 10:23:57 -0400, Chet Ramey wrote: > On 10/16/20 9:28 AM, Chet Ramey wrote: > > On 10/16/20 9:16 AM, Dr. Werner Fink wrote: > > > >> Also a warning hint in the manual page could > >> help users before enabling this feature :) > > > > I agree, and the manual page in the release will reflect bracketed paste's > > default setting. However, readline doesn't try to enable bracketed paste if > > tcgetattr fails, which it will on an fd that's not a terminal, so I am > > fairly sure that expect/pexpect use ptys to masquerade as terminals. > > > > The biggest problem with bracketed paste is that right now, there's simply > > no way to determine whether or not a particular terminal supports it. > > I wonder if it would make sense for bash to compile its version of readline > with bracketed paste on by default, but the standalone readline library > version have it off. Or is that too clever by half? Ohmm ... this makes no diffference here as bash (and all other tools) uses, if ever possible, the system libraries by policy. And the readline library is a system library. That means if there is a security issue within such a system library it has to be fixed only once. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 2020/10/16 09:03:53 -0400, Chet Ramey wrote:
> On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> > Hi,
> >
> > after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> > staging process. During build the package python-pexpect throws errors
> > in its test suite, e.g.
> >
> > [ 260s] self = > testMethod=test_async_replwrap_multiline>
> > [ 260s]
> > [ 260s] def test_async_replwrap_multiline(self):
> > [ 260s] bash = replwrap.bash()
> > [ 260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
> > [ 260s] res = run(coro)
> > [ 260s] > self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
> > [ 260s] E AssertionError: Lists differ: ['\x1b[?2004l',
> > '\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
> > [ 260s] E
> > [ 260s] E First differing element 0:
> > [ 260s] E '\x1b[?2004l'
> > [ 260s] E '1 2'
> > [ 260s] E
> > [ 260s] E First list contains 3 additional elements.
> > [ 260s] E First extra element 2:
> > [ 260s] E '1 2'
> > [ 260s] E
> > [ 260s] E - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4',
> > '\x1b[?2004h']
> > [ 260s] E + ['1 2', '3 4']
> >
> > I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the
> > sequences
> > are defined in rlprivate.h
> >
> > #define BRACK_PASTE_INIT "\033[?2004h"
> > #define BRACK_PASTE_FINI "\033[?2004l\r"
> >
> > indeed it is a nice feature to see highlighted paste content on the
> > interactive
> > command line, but why this interferes with tools like pexpect using bash in
> > interactive mode?
>
> Yes, bracketed paste is currently enabled by default. I may change that by
> the time 5.1 is released.
>
> I don't understand your question about tools like pexpect. If bracketed
> paste mode is on, it's on. How is readline supposed to know whether or not
> its stdin and stdout are connected to expect? How is the interactive shell
> run by pexpect different from one connected to a terminal?
I'm aware that if tools like pexpect uses a terminal emulator there is not
way to detect this. If this feature can (in principal) not distinguish between
a real paste on a real command line and input from an (p)expect tools then it
should (IMHO) not be enabled. Also a warning hint in the manual page could
help users before enabling this feature :)
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
Hi,
after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
staging process. During build the package python-pexpect throws errors
in its test suite, e.g.
[ 260s] self =
[ 260s]
[ 260s] def test_async_replwrap_multiline(self):
[ 260s] bash = replwrap.bash()
[ 260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
[ 260s] res = run(coro)
[ 260s] > self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
[ 260s] E AssertionError: Lists differ: ['\x1b[?2004l',
'\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
[ 260s] E
[ 260s] E First differing element 0:
[ 260s] E '\x1b[?2004l'
[ 260s] E '1 2'
[ 260s] E
[ 260s] E First list contains 3 additional elements.
[ 260s] E First extra element 2:
[ 260s] E '1 2'
[ 260s] E
[ 260s] E - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4',
'\x1b[?2004h']
[ 260s] E + ['1 2', '3 4']
I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the sequences
are defined in rlprivate.h
#define BRACK_PASTE_INIT "\033[?2004h"
#define BRACK_PASTE_FINI "\033[?2004l\r"
indeed it is a nice feature to see highlighted paste content on the interactive
command line, but why this interferes with tools like pexpect using bash in
interactive mode?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: [bug-bash] Unexpected sourcing of ~/.bashrc under ssh
On 2019/10/24 10:47:52 -0400, Greg Wooledge wrote: > On Thu, Oct 24, 2019 at 09:01:07AM +0200, francis.montag...@inria.fr wrote: > > When logged on a machine with ssh, executing a simple command CMD1 > > that spawn a "/bin/bash -c some other command" do not source > > ~/.bashrc: normal behaviour. > > > > When executing "CMD1 | CMD2", the ~/.bashrc is sourced: wrong . > > Bash can be built with a compile-time option that causes it to try to > detect when it's the non-interactive child of an ssh session, and source > the user's ~/.bashrc under those conditions. > > Many Linux distributions enable this option, because they believe that > their users expect this behavior. That is what bugzilla had told the last few years here, most users and customers expect that their bash bahaves (non-)interactive local and remote the same way -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: Hidden directories breaks path expansions
On Fri, Mar 08, 2019 at 09:53:39AM -0500, Chet Ramey wrote: > On 3/7/19 9:42 AM, Dr. Werner Fink wrote: > > >> There is a slightly updated version of that patch attached to this message. > > > > OK ... the hidden directories do work now ... but in the test suite > > of sed the test case sed-4.7/testsuite/subst-mb-incomplete.sh with > > > > print_ver_ sed > > > > require_en_utf8_locale_ > > > > echo > in || framework_failure_ > > printf '\233\375\200\n' > exp-out || framework_failure_ > > > > LC_ALL=en_US.utf8 sed $(printf 's/^/\\L\233\375\\\200/') in > out 2> err > > > > compare exp-out out || fail=1 > > compare /dev/null err || fail=1 > > > > Exit $fail > > > > does fail (YaOB). > > I've attached an updated version of the patch. It will fix this. The glob > engine shouldn't return a dequoted version of the pattern unless it > matches something (and, based on historical behavior, maybe not even then). > > Ironically, we're about to start another discussion on the POSIX mailing > list about how backslashes in shell patterns should behave. It's always > fun to shoot at a moving target. It works! Thanks a lot! Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: [bug-bash] Hidden directories breaks path expansions
On Thu, Mar 07, 2019 at 03:42:49PM +0100, Dr. Werner Fink wrote: > On Mon, Mar 04, 2019 at 09:00:38AM -0500, Chet Ramey wrote: > > On 3/4/19 8:19 AM, wer...@suse.de wrote: > > > > > Bash Version: 5.0 > > > Patch Level: 2 > > > Release Status: release > > > > > > Description: > > > Since patch bash50-001 there is a regession on path expansion. > > > The script example below shows: > > > > > > bash/bash> bash tmp/bug.sh > > > 5.0.2(1)-release > > > drwxr-xr-x 2 nobody root 17 Mar 4 14:08 . > > > > > > bash/bash> /dist/unpacked/sle15-x86_64.full/bin/bash tmp/bug.sh > > > 4.4.23(1)-release > > > -rw-r--r-- 1 nobody root 0 Mar 4 14:10 > > > /tmp/bugthroughpatch001/hidden/foo/bar > > > > > > Disabling patch bash50-001 solves this problem but cause > > > other problems. It seems as seen by strace and ltrace that > > > the bash with patch bash50-001 now makes a stat(2) on every > > > single part of the path and run onto EACCES error which cause > > > the regression above. > > > > http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00151.html > > > > There is a slightly updated version of that patch attached to this message. > > OK ... the hidden directories do work now ... but in the test suite > of sed the test case sed-4.7/testsuite/subst-mb-incomplete.sh with > > print_ver_ sed > > require_en_utf8_locale_ > > echo > in || framework_failure_ > printf '\233\375\200\n' > exp-out || framework_failure_ > > LC_ALL=en_US.utf8 sed $(printf 's/^/\\L\233\375\\\200/') in > out 2> err > > compare exp-out out || fail=1 > compare /dev/null err || fail=1 > > Exit $fail > > does fail (YaOB). This is the resulting log file from the testsuite --- exp-out 2019-03-07 16:29:24.554957850 + +++ out 2019-03-07 16:29:24.558957897 + @@ -1 +1 @@ -�375200 +L�375200 FAIL testsuite/subst-mb-incomplete.sh (exit status: 1) -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: Hidden directories breaks path expansions
On Mon, Mar 04, 2019 at 09:00:38AM -0500, Chet Ramey wrote: > On 3/4/19 8:19 AM, wer...@suse.de wrote: > > > Bash Version: 5.0 > > Patch Level: 2 > > Release Status: release > > > > Description: > > Since patch bash50-001 there is a regession on path expansion. > > The script example below shows: > > > > bash/bash> bash tmp/bug.sh > > 5.0.2(1)-release > > drwxr-xr-x 2 nobody root 17 Mar 4 14:08 . > > > > bash/bash> /dist/unpacked/sle15-x86_64.full/bin/bash tmp/bug.sh > > 4.4.23(1)-release > > -rw-r--r-- 1 nobody root 0 Mar 4 14:10 > > /tmp/bugthroughpatch001/hidden/foo/bar > > > > Disabling patch bash50-001 solves this problem but cause > > other problems. It seems as seen by strace and ltrace that > > the bash with patch bash50-001 now makes a stat(2) on every > > single part of the path and run onto EACCES error which cause > > the regression above. > > http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00151.html > > There is a slightly updated version of that patch attached to this message. OK ... the hidden directories do work now ... but in the test suite of sed the test case sed-4.7/testsuite/subst-mb-incomplete.sh with print_ver_ sed require_en_utf8_locale_ echo > in || framework_failure_ printf '\233\375\200\n' > exp-out || framework_failure_ LC_ALL=en_US.utf8 sed $(printf 's/^/\\L\233\375\\\200/') in > out 2> err compare exp-out out || fail=1 compare /dev/null err || fail=1 Exit $fail does fail (YaOB). Werner > -- > ``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/ -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: [bug-bash] Bash-5.0-beta2 available for download
On Thu, Nov 29, 2018 at 08:52:58AM -0800, Chet Ramey wrote: > On 11/29/18 7:09 AM, Dr. Werner Fink wrote: > > On Tue, Nov 27, 2018 at 01:24:38PM -0500, Chet Ramey wrote: > >> The second beta release of bash-5.0 is now available with the URL > >> > >> ftp://ftp.cwru.edu/pub/bash/bash-5.0-beta2.tar.gz > >> > > I see this > > > > [ 2709s] seq.c: In function 'long_double_format': > > [ 2709s] seq.c:166:9: error: expected ';' before 'return' > > [ 2709s] return ldfmt; > > Thanks. What are you using that doesn't have long double? Seen on armv7l only :) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: [bug-bash] Bash-5.0-beta2 available for download
On Tue, Nov 27, 2018 at 01:24:38PM -0500, Chet Ramey wrote: > The second beta release of bash-5.0 is now available with the URL > > ftp://ftp.cwru.edu/pub/bash/bash-5.0-beta2.tar.gz > I see this [ 2709s] seq.c: In function 'long_double_format': [ 2709s] seq.c:166:9: error: expected ';' before 'return' [ 2709s] return ldfmt; [ 2709s] ^~ with attached patcj this should go away -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr --- bash-5.0-beta2/examples/loadables/seq.c +++ bash-5.0-beta2/examples/loadables/seq.c 2018-11-29 15:06:37.818582755 + @@ -161,7 +161,7 @@ long_double_format (char const *fmt) strcpy (ldfmt + length_modifier_offset + 1, fmt + length_modifier_offset + has_L); #else -strcpy (ldfmt + length_modifier_offset, fmt + length_modifier_offset) +strcpy (ldfmt + length_modifier_offset, fmt + length_modifier_offset); #endif return ldfmt; } signature.asc Description: PGP signature
Re: [bug-bash] Which commit for a bug in 4.3.48 which is fixed in 4.4.23
On Mon, Sep 24, 2018 at 01:52:54PM -0400, Chet Ramey wrote: > On 9/24/18 1:50 PM, Eduardo Bustamante wrote: > > On Mon, Sep 24, 2018 at 4:09 AM Dr. Werner Fink wrote: > > (...) > >> Reconstructed the attached patch ... seems to work > > > > Out of curiosity, what problem are you trying to solve? > > https://bugzilla.novell.com/show_bug.cgi?id=1107430 Yep ... or as I prefer https://bugzilla.opensuse.org/show_bug.cgi?id=1107430 here a version upgrade is a no-go -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: [bug-bash] Which commit for a bug in 4.3.48 which is fixed in 4.4.23
On Fri, Sep 21, 2018 at 01:11:38PM +0200, Dr. Werner Fink wrote:
> Hi,
>
> with 4.3.48 the line
>
> T="";echo ">${T//*/ }<"
>
> leads to
>
> ><
>
> but with 4.4.23 the correct result is given back
>
> > <
>
> in the git repro I do not find any useful login entry for this
Reconstructed the attached patch ... seems to work
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Fix `*' matches any string, including the null string as e.g.
T=""
echo ">${T//*/ }<"
had not worked,, that is return string "> <"
---
lib/glob/gmisc.c |4 ++--
subst.c | 20 +---
2 files changed, 19 insertions(+), 5 deletions(-)
--- subst.c
+++ subst.c 2018-09-24 10:46:21.913346656 +
@@ -4396,7 +4396,7 @@ match_pattern (string, pat, mtype, sp, e
size_t slen, plen, mslen, mplen;
#endif
- if (string == 0 || *string == 0 || pat == 0 || *pat == 0)
+ if (string == 0 || pat == 0 || *pat == 0)
return (0);
#if defined (HANDLE_MULTIBYTE)
@@ -6453,6 +6453,7 @@ get_var_and_type (varname, value, ind, q
{
if (value && vtype == VT_VARIABLE)
{
+ *varp = find_variable (vname);
if (quoted & (Q_DOUBLE_QUOTES|Q_HERE_DOCUMENT))
*valp = dequote_string (value);
else
@@ -6642,6 +6643,8 @@ pat_subst (string, pat, rep, mflags)
* with REP and return the result.
* 2. A null pattern with mtype == MATCH_END means to append REP to
* STRING and return the result.
+ * 3. A null STRING with a matching pattern means to append REP to
+ * STRING and return the result.
* These don't understand or process `&' in the replacement string.
*/
if ((pat == 0 || *pat == 0) && (mtype == MATCH_BEG || mtype == MATCH_END))
@@ -6663,17 +,27 @@ pat_subst (string, pat, rep, mflags)
}
return (ret);
}
+ else if (*string == 0 && (match_pattern (string, pat, mtype, &s, &e) != 0))
+{
+ replen = STRLEN (rep);
+ ret = (char *)xmalloc (replen + 1);
+ if (replen == 0)
+ ret[0] = '\0';
+ else
+ strcpy (ret, rep);
+ return (ret);
+}
ret = (char *)xmalloc (rsize = 64);
ret[0] = '\0';
- for (replen = STRLEN (rep), rptr = 0, str = string;;)
+ for (replen = STRLEN (rep), rptr = 0, str = string; *str;)
{
if (match_pattern (str, pat, mtype, &s, &e) == 0)
break;
l = s - str;
- if (rxpand)
+ if (rep && rxpand)
{
int x;
mlen = e - s;
@@ -6682,6 +6695,7 @@ pat_subst (string, pat, rep, mflags)
mstr[x] = s[x];
mstr[mlen] = '\0';
rstr = strcreplace (rep, '&', mstr, 0);
+ free (mstr);
rslen = strlen (rstr);
}
else
--- lib/glob/gmisc.c
+++ lib/glob/gmisc.c2018-09-24 10:46:30.673185840 +
@@ -53,7 +53,7 @@ match_pattern_wchar (wpat, wstring)
wchar_t wc;
if (*wstring == 0)
-return (0);
+return (*wpat == L'*');/* XXX - allow only * to match empty string */
switch (wc = *wpat++)
{
@@ -230,7 +230,7 @@ match_pattern_char (pat, string)
char c;
if (*string == 0)
-return (0);
+return (*pat == '*'); /* XXX - allow only * to match empty string */
switch (c = *pat++)
{
signature.asc
Description: PGP signature
Which commit for a bug in 4.3.48 which is fixed in 4.4.23
Hi,
with 4.3.48 the line
T="";echo ">${T//*/ }<"
leads to
><
but with 4.4.23 the correct result is given back
> <
in the git repro I do not find any useful login entry for this
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: Syntax error near unexpected token `newline' within loops
On Mon, Apr 24, 2017 at 08:44:11AM -0400, Greg Wooledge wrote:
> On Mon, Apr 24, 2017 at 12:59:01PM +0200, wer...@suse.de wrote:
> > V_NAME=Friday
> > for (( INDEX=0; INDEX<$((10-$(expr length $V_NAME))); INDEX++ ))
>
> The outer (( )) in the C-style for loop already create an arithmetic
> expression context. You don't need to use $(( )) inside them. You can
> simply write:
>
> for (( INDEX=0; INDEX<10-${#V_NAME};; INDEX++ ))
>
> By the way, the [ ] index syntax in an indexed (not associative) array
> expansion works the same way. You can simply write:
>
> "${a[x+1]}"
>
> instead of
>
> "${a[$((x+1))]}"
Yes I know ... nevertheless, the initial code should not trigger an error
... to make it sure, the initial example was given by a user asking me
why this triggers an error, which IMHO it should not.
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: Syntax error near unexpected token `newline' within loops
On Mon, Apr 24, 2017 at 02:25:41PM +0300, Pierre Gaston wrote:
> On Mon, Apr 24, 2017 at 1:59 PM, wrote:
>
> > (...)
> >
> > and yes
> >
> > V_NAME=Friday
> > for (( INDEX=0; INDEX<$((10-${#V_NAME})) ; INDEX++ ))
> > do
> > echo $INDEX
> > done
> >
> > does also work, nevertheless using $(...) in the very first example is
> > allowed
> >
> >
> or even for (( INDEX=0; INDEX<(10-${#V_NAME}) ; INDEX++ ))
> but otherwise yes, syntax looks ok
Yep ... the code could be more efficiently like
V_NAME=Friday
typeset -i len=$((10 - ${#V_NAME}))
for (( INDEX=0; INDEX < len; INDEX++ )); do echo $INDEX; done
... nevertheless even the intricate code should not cause an error I guess :)
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: The lastpipe shell option even with job control?
On Tue, Mar 28, 2017 at 10:17:54AM -0400, Chet Ramey wrote: > On 3/27/17 9:44 AM, Dr. Werner Fink wrote: > > Hi, > > > > I'd like to ask if there is crucial reason, beside the correct foreground > > process group, not to allow the lastpipe shell option for an interactive > > bash? Maybe something like in the attachment could be an option? > > Yes, there is. Once you decide you're going to allow lastpipe when job > control is enabled, you commit to handling ^Z and allowing the user to > suspend that pipeline. You have to do something with the foreground > shell at that point. An interactive shell is already ignoring SIGTSTP, > so you'll have to undo that, set a handler, figure out where you are, > and decide what to do. > > Some other shells attempt to solve the problem by forking (from the > TSTP handler??) cleaning up all the state, juggling the jobs table and > process status, and letting the forked shell continue with the pipeline, > but that's really fragile and I've never been tempted to implement it. AFAICR this is what ksh93 does in sh_exit() ... zsh seems to write out something like `zsh: job can't be suspended' for builtins Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
The lastpipe shell option even with job control?
Hi,
I'd like to ask if there is crucial reason, beside the correct foreground
process group, not to allow the lastpipe shell option for an interactive
bash? Maybe something like in the attachment could be an option?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
diff --git execute_cmd.c execute_cmd.c
index 2a3df6d..9802303 100644
--- execute_cmd.c
+++ execute_cmd.c
@@ -2346,6 +2346,16 @@ lastpipe_cleanup (s)
unfreeze_jobs_list ();
}
+extern int shell_tty;
+
+static void
+restore_tty (s)
+ pid_t s;
+{
+ if (s > 0)
+give_terminal_to (s, 0);
+}
+
static int
execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
COMMAND *command;
@@ -2360,7 +2370,9 @@ execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
#if defined (JOB_CONTROL)
sigset_t set, oset;
+ pid_t cpgrp;
BLOCK_CHILD (set, oset);
+ cpgrp = shell_tty >= 0 ? tcgetpgrp (shell_tty) : -1;
#endif /* JOB_CONTROL */
ignore_return = (command->flags & CMD_IGNORE_RETURN) != 0;
@@ -2459,7 +2471,7 @@ execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
/* If the `lastpipe' option is set with shopt, and job control is not
enabled, execute the last element of non-async pipelines in the
current shell environment. */
- if (lastpipe_opt && job_control == 0 && asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
+ if (lastpipe_opt && asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
{
lstdin = move_to_high_fd (0, 1, -1);
if (lstdin > 0)
@@ -2467,6 +2479,7 @@ execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
do_piping (prev, pipe_out);
prev = NO_PIPE;
add_unwind_protect (restore_stdin, lstdin);
+ add_unwind_protect (restore_tty, cpgrp);
lastpipe_flag = 1;
freeze_jobs_list ();
lastpipe_jid = stop_pipeline (0, (COMMAND *)NULL); /* XXX */
@@ -2516,7 +2529,9 @@ execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
else if (pipefail_opt)
exec_result = exec_result | lstdin; /* XXX */
/* otherwise we use exec_result */
-
+
+ if (cpgrp > 0)
+ give_terminal_to (cpgrp, 0);
#endif
unfreeze_jobs_list ();
}
diff --git doc/bash.0 doc/bash.0
index 031be8a..6cfe061 100644
--- doc/bash.0
+++ doc/bash.0
@@ -5507,9 +5507,8 @@ SSHHEELLLL BBUUIILLTTIINN CCOOMMMMAANNDDSS
in an interactive shell (see CCOOMMMMEENNTTSS above). This
option is enabled by default.
llaassttppiippee
- If set, and job control is not active, the shell runs
- the last command of a pipeline not executed in the back-
- ground in the current shell environment.
+ If set the shell runs the last command of a pipeline not
+ executed in the background in the current shell environment.
lliitthhiisstt If set, and the ccmmddhhiisstt option is enabled, multi-line
commands are saved to the history with embedded newlines
rather than using semicolon separators where possible.
diff --git doc/bash.1 doc/bash.1
index 9a7a384..8327867 100644
--- doc/bash.1
+++ doc/bash.1
@@ -9788,8 +9788,8 @@ line to be ignored in an interactive shell (see
above). This option is enabled by default.
.TP 8
.B lastpipe
-If set, and job control is not active, the shell runs the last command of
-a pipeline not executed in the background in the current shell environment.
+If set the shell runs the last command of a pipeline not
+executed in the background in the current shell environment.
.TP 8
.B lithist
If set, and the
diff --git doc/bash.html doc/bash.html
index 983284e..2a2b242 100644
--- doc/bash.html
+++ doc/bash.html
@@ -12431,8 +12431,8 @@ above). This option is enabled by default.
lastpipe
-If set, and job control is not active, the shell runs the last command of
-a pipeline not executed in the background in the current shell environment.
+If set the shell runs the last command of a pipeline not
+executed in the background in the current shell environment.
lithist
diff --git doc/bash.info doc/bash.info
index fac6786..6dd1c77 100644
--- doc/bash.info
+++ doc/bash.info
@@ -4504,9 +4504,8 @@ This builtin allows you to change additional shell optional behavior.
interactive shell. This option is enabled by default.
'lastpipe'
- If set, and job control is not active, the shell runs the last
- command of a pipeline not executed in the background in the
- current shell environment.
+ If set the shell runs the last command of a pipeline not
+ executed in the background in the current shell environment.
'lithist'
If enabled, and the 'cmdhis
The trap EXIT not allways executed
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.4
-L/home/abuild/rpmbuild/BUILD/bash-4.4/../readline-7.0
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0
-grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE -DRECYCLES_PIDS
-Wall -g -Wuninitialized -Wextra -Wno-switch-enum -Wno-unused-variable
-Wno-unused-parameter -Wno-parentheses -ftree-loop-linear -pipe -DBNC382214=0
-DIMPORT_FUNCTIONS_DEF=0 -fprofile-use
uname output: Linux noether 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20
08:03:29 UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.4
Patch Level: 0
Release Status: release
openSUSE Bug: 1008459
Description:
The trap EXIT not allways executed, see example script
Repeat-By:
Example script
#!/bin/bash
bash -c '
_rm () { echo ATT: Execute trap function; }
trap _rm EXIT
rm -f doesnotexist
'
echo $?
bash -c '
_rm () { echo ATT: Execute trap function; }
rm -f doesnotexist
trap _rm EXIT
'
echo $?
which results in
0
ATT: Execute trap function
0
signature.asc
Description: PGP signature
Trap does not work if a subshell wait(s) for job
Hi,
found due to a hang in the test suite of gnutls, after debugging I've
extract the example code
launch_server () { sleep 100 & l=$!; trap "kill -15 $l" 15; echo $l; wait
$l; }
launch_server & x=$!
sleep 2
kill $x
which does wait the full 100 seconds with bash 4.3 but with the old bash 4.2
only 2 seconds.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: Digital signature
Re: [bug-bash] Named fifo's causing hanging bash scripts
On Fri, Jan 16, 2015 at 10:46:02AM -0500, Chet Ramey wrote: > >> > >> What do ps and gdb tell you about pid 19175 (and the corresponding pid in > >> the call to waitchld in the other traceback)? Running, terminated, reaped, > >> other? > > > > d136:~ # ps 10942 > > PID TTY STAT TIME COMMAND > > d136:~ # > > > > ... the process does not exists anymore. I guess that this could belong to > > the sed commands of the script. > > This is why I need to be able to reproduce it. If the process got reaped, > when would it have happened and why would the call to wait_for() have > found a valid CHILD struct for it? The whole loop runs with SIGCHLD > blocked, so it's not as if the signal handler could have reaped the > child out from under it. I have questions but no way to find answers. OK, thanks for your effort ... I've strip the spec file down step by step and reached success at commenting out -DMUST_UNBLOCK_CHLD=1 (mea culpa) ... many thanks for your help! Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: Digital signature
Re: [bug-bash] Named fifo's causing hanging bash scripts
On Fri, Jan 16, 2015 at 09:22:36AM -0500, Chet Ramey wrote: > On 1/13/15 4:29 AM, Dr. Werner Fink wrote: > > >>> Bash Version: 4.3 > >>> Patch Level: 33 > >>> Release Status: release > >>> > >>> Description: > >>> Named fifo's causing hanging bash scripts like > >>> > >>> while IFS="|" read a b c ; do > >>> [shell code] > >>> done < <(shell code) > >>> > >>> can cause random hangs of the bash.An strace shows that the > >>> bash > >>> stays in wait4() > >> > >> And when you attach to one of the hanging bash processes using gdb, what > >> does the stack traceback look like? > > > > Yes (and sorry for the wrong email address as this was done on a clean > > virtual sysstem) > > > > there are two hanging bash processes together with the find command: > > > > werner 19062 0.8 0.0 11864 2868 ttyS0S+ 10:21 0:00 bash -x > > /tmp/brp-25-symlink > > werner 19063 0.0 0.0 11860 1920 ttyS0S+ 10:21 0:00 bash -x > > /tmp/brp-25-symlink > > werner 19064 0.2 0.0 16684 2516 ttyS0S+ 10:21 0:00 find . > > -type l -printf %p|%h|%l n > > > > the gdb -p 19062 and gdb -p 19063 show > > > > (gdb) bt > > #0 0x7f530818a65c in waitpid () from /lib64/libc.so.6 > > #1 0x0042b233 in waitchld (block=block@entry=1, wpid=19175) at > > jobs.c:3235 > > #2 0x0042c6da in wait_for (pid=pid@entry=19175) at jobs.c:2496 > > What do ps and gdb tell you about pid 19175 (and the corresponding pid in > the call to waitchld in the other traceback)? Running, terminated, reaped, > other? d136:~ # ps 10942 PID TTY STAT TIME COMMAND d136:~ # ... the process does not exists anymore. I guess that this could belong to the sed commands of the script. The other thread is showing d136: # ps 10922 PID TTY STAT TIME COMMAND 13177 pts/1S+ 0:00 find . -type l -printf %p|%h|%l n and the backtrace shows here 0x7fccae8d4860 in __write_nocancel () from /lib64/libc.so.6 #0 0x7fccae8d4860 in __write_nocancel () from /lib64/libc.so.6 #1 0x7fccae86f6b3 in _IO_new_file_write () from /lib64/libc.so.6 #2 0x7fccae86ed73 in new_do_write () from /lib64/libc.so.6 #3 0x7fccae8704e5 in __GI__IO_do_write () from /lib64/libc.so.6 #4 0x7fccae86fbe1 in __GI__IO_file_xsputn () from /lib64/libc.so.6 #5 0x7fccae8416e0 in vfprintf () from /lib64/libc.so.6 #6 0x7fccae8eec05 in __fprintf_chk () from /lib64/libc.so.6 #7 0x004106d5 in ?? () #8 0x0040a11b in ?? () #9 0x0040afa9 in ?? () #10 0x0040b0a6 in ?? () #11 0x00409bfe in ?? () #12 0x00409bfe in ?? () #13 0x00404199 in ?? () #14 0x00403911 in ?? () #15 0x7fccae81cb05 in __libc_start_main () from /lib64/libc.so.6 #16 0x004039dd in ?? () which IMHO could be related that output of find is not read anymore(?) > > Chet Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: Digital signature
Re: Named fifo's causing hanging bash scripts
On Fri, Jan 16, 2015 at 09:09:25AM -0500, Chet Ramey wrote: > On 1/12/15 9:55 AM, wer...@linux-8jdz.site wrote: > > > Bash Version: 4.3 > > Patch Level: 33 > > Release Status: release > > > > Description: > > Named fifo's causing hanging bash scripts like > > > > while IFS="|" read a b c ; do > > [shell code] > > done < <(shell code) > > > > can cause random hangs of the bash.An strace shows that the bash > > stays in wait4() > > I can't reproduce this. I spun up a VM running OpenSUSE 13 and ran the > attached script against a version of bash-4.3.33 that was modified to use > FIFOs instead of /dev/fd. There were no hangs in any of about 30 runs. Hmmm ... what I see is werner 10920 0.0 0.0 11860 2876 pts/1S+ 15:59 0:00 bash /tmp/brp-25-symlink werner 10921 0.0 0.0 11856 1844 pts/1S+ 15:59 0:00 bash /tmp/brp-25-symlink werner 10922 0.0 0.0 16684 2476 pts/1S+ 15:59 0:00 find . -type l -printf %p|%h|%l n d136:~ # ll /proc/10920/fd total 0 lr-x-- 1 werner suse 64 Jan 16 15:59 0 -> pipe:[124428] lrwx-- 1 werner suse 64 Jan 16 15:59 1 -> /dev/pts/1 lrwx-- 1 werner suse 64 Jan 16 15:59 10 -> /dev/pts/1 lrwx-- 1 werner suse 64 Jan 16 15:59 2 -> /dev/pts/1 lr-x-- 1 werner suse 64 Jan 16 15:59 255 -> /tmp/brp-25-symlink d136:~ # ll /proc/10921/fd total 0 lrwx-- 1 werner suse 64 Jan 16 15:59 0 -> /dev/pts/1 l-wx-- 1 werner suse 64 Jan 16 15:59 1 -> pipe:[124428] lrwx-- 1 werner suse 64 Jan 16 15:59 2 -> /dev/pts/1 ... but in the build there is [ 131s] checking for mkfifo... yes [ 150s] execute_cmd.c: In function 'execute_command_internal': [ 150s] execute_cmd.c:1034:12: warning: 'ofifo_list' may be used uninitialized in this function [-Wmaybe-uninitialized] [ 150s]free ((void *)ofifo_list); [ 150s] ^ and currently the bash43 is not usable for the OBS here. Also my personal chrootx script using <() for fiddling with xauth hangs upto Ctrl-C. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: Digital signature
Re: [bug-bash] Named fifo's causing hanging bash scripts
On Mon, Jan 12, 2015 at 11:50:56AM -0500, Chet Ramey wrote: > On 1/12/15 9:55 AM, wer...@linux-8jdz.site wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.3 > > -L/home/abuild/rpmbuild/BUILD/bash-4.3/../readline-6.3 > > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' > > -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 > > -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector > > -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE > > -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-unprototyped-calls > > -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter > > -Wno-parentheses -ftree-loop-linear -pipe -DBNC382214=0 > > -DMUST_UNBLOCK_CHLD=1 -DIMPORT_FUNCTIONS_DEF=0 -fprofile-use > > uname output: Linux d136 3.15.0-rc7-3-desktop #1 SMP PREEMPT Wed May 28 > > 15:39:51 UTC 2014 (96f5b60) x86_64 x86_64 x86_64 GNU/Linux > > Machine Type: x86_64-suse-linux-gnu > > > > Bash Version: 4.3 > > Patch Level: 33 > > Release Status: release > > > > Description: > > Named fifo's causing hanging bash scripts like > > > > while IFS="|" read a b c ; do > > [shell code] > > done < <(shell code) > > > > can cause random hangs of the bash.An strace shows that the bash > > stays in wait4() > > And when you attach to one of the hanging bash processes using gdb, what > does the stack traceback look like? Yes (and sorry for the wrong email address as this was done on a clean virtual sysstem) there are two hanging bash processes together with the find command: werner 19062 0.8 0.0 11864 2868 ttyS0S+ 10:21 0:00 bash -x /tmp/brp-25-symlink werner 19063 0.0 0.0 11860 1920 ttyS0S+ 10:21 0:00 bash -x /tmp/brp-25-symlink werner 19064 0.2 0.0 16684 2516 ttyS0S+ 10:21 0:00 find . -type l -printf %p|%h|%l n the gdb -p 19062 and gdb -p 19063 show (gdb) bt #0 0x7f530818a65c in waitpid () from /lib64/libc.so.6 #1 0x0042b233 in waitchld (block=block@entry=1, wpid=19175) at jobs.c:3235 #2 0x0042c6da in wait_for (pid=pid@entry=19175) at jobs.c:2496 #3 0x004302e1 in command_substitute (string=string@entry=0x22ccd80 "dirname_int $link", quoted=quoted@entry=1) at subst.c:5534 #4 0x004704db in param_expand (string=string@entry=0x22cc8d0 "$(dirname_int $link)", sindex=sindex@entry=0x7fff39f90ef0, quoted=quoted@entry=1, expanded_something=expanded_something@entry=0x0, contains_dollar_at=contains_dollar_at@entry=0x7fff39f90f20, quoted_dollar_at_p=quoted_dollar_at_p@entry=0x7fff39f90f00, had_quoted_null_p=had_quoted_null_p@entry=0x7fff39f90f10, pflags=0) at subst.c:7970 #5 0x00471123 in expand_word_internal (word=word@entry=0x22cc1a0, quoted=quoted@entry=1, isexp=isexp@entry=0, contains_dollar_at=contains_dollar_at@entry=0x7fff39f91080, expanded_something=expanded_something@entry=0x0) at subst.c:8393 #6 0x0047130f in expand_word_internal (word=word@entry=0x7fff39f91120, quoted=quoted@entry=0, isexp=isexp@entry=0, contains_dollar_at=contains_dollar_at@entry=0x0, expanded_something=expanded_something@entry=0x0) at subst.c:8548 #7 0x00472daf in call_expand_word_internal (e=0x0, c=0x0, i=0, q=0, w=0x7fff39f91120) at subst.c:3299 #8 expand_string_assignment (string=string@entry=0x22cb159 "\"$(dirname_int $link)\"", quoted=quoted@entry=0) at subst.c:3387 #9 0x00473110 in expand_string_if_necessary (string=, string@entry=0x22cb159 "\"$(dirname_int $link)\"", quoted=quoted@entry=0, func=func@entry=0x472d50 ) at subst.c:3092 #10 0x00473349 in do_assignment_internal (word=0x22cbbe0, expand=1) at subst.c:2823 #11 0x0047776a in do_word_assignment (flags=, word=) at subst.c:2912 #12 expand_word_list_internal (eflags=, list=) at subst.c:9669 #13 expand_words (list=0x) at subst.c:9280 #14 0x00461093 in execute_simple_command (simple_command=0x22c1ed0, pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1, async=async@entry=0, fds_to_close=fds_to_close@entry=0x22ccce0) at execute_cmd.c:4001 #15 0x004629fc in execute_command_internal (command=0x22bc9e0, asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1, fds_to_close=fds_to_close@entry=0x22ccce0) at execute_cmd.c:788 #16 0x00462ba6 in execute_connection (fds_to_close=0x22ccce0, pipe_out=-1, pipe_in=-1, asynchronous=0, command=0x22c0bd0) at execute_cmd.c:2497 #17 execute_command_internal (command=command@entry=0x22c0bd0, asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, pipe_out=p
Re: [bug-bash] Troublesome checkwinsize (none) behaviour
On Sat, Jul 13, 2013 at 02:52:07AM -0700, Linda Walsh wrote: > Not even putting an underscore in front or back of it. 'path' is a > not an uncommon name for shell scripts to use. > > Also, I assume you know that suse scripts export COLUMNS in places > like /etc/profile, /etc/csh.login and /etc/ksh.kshrc... Not for normal login sessions or do you work on/with an iSeries? > Perhaps one of those is propagating to the error cases mentioned? No it is not. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr pgp7e1hUU8ydH.pgp Description: PGP signature
Warning: the patch for xdupmbstowcs2 to avoid loops breaks expansion
Hi,
just to be noted, tha patch:
-
*** ../bash-4.2-patched/lib/glob/xmbsrtowcs.c 2010-05-30 18:36:27.0
-0400
--- lib/glob/xmbsrtowcs.c 2011-03-14 14:22:11.0 -0400
***
*** 174,180
wcslength = mbsnrtowcs(NULL, &tmp_p, nms, 0, &tmp_state);
/* Conversion failed. */
! if (wcslength == (size_t)-1)
{
free (wsbuf);
*destp = NULL;
--- 174,180
wcslength = mbsnrtowcs(NULL, &tmp_p, nms, 0, &tmp_state);
/* Conversion failed. */
! if (wcslength == 0 || wcslength == (size_t)-1)
{
free (wsbuf);
*destp = NULL;
-
just breaks expansion like this one:
> mkdir aaa
> touch aaa/foo.a
> touch aaa/foo.b
> echo './aaa/foo'*
./aaa/foo*
in an arbitrary UTF-8 locale
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Tue, Mar 08, 2011 at 09:40:26PM -0500, Chet Ramey wrote: > On 3/8/11 11:12 AM, Chet Ramey wrote: > > > I might be able to finesse this particular case based on the state that > > readline exports to the calling application. > > I think I was able to do that. Try the attached patch; it works for me. > It identifies a single specific common case and allows the history to be > saved in that case. I think that case minimizes the chances of deadlock, > but it requires much more testing before I will be convinced. Please help > me out by testing it. The patch does its work, thanks a lot. > Yes, I know that it's not 100% safe and will run unsafe functions from a > signal handler. I will devise a better fix for later, but that will > require changes to readline (so it can catch SIGHUP) that will have to > wait. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote: > > > > Does this mean that the attached patch could also not work > > on some systems? Or does this interfere with the readline > > library? > > Since longjmp is not on the list of functions that is safe to call > from a signal handler, yes, that's what it means. OTOH, this shows > promise as a solution. OK, that means only for systems with HAVE_POSIX_SIGSETJMP defined. At least this provides a (local) solution here Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Tue, Mar 08, 2011 at 11:19:25AM -0500, Chet Ramey wrote:
> On 3/8/11 5:29 AM, Dr. Werner Fink wrote:
>
> >> One thing that has changed is that an interactive shell will no longer
> >> attempt to write the history file if it's killed by a signal, since that
> >> causes many functions to be executed that are not safe to call from a
> >> signal handler. If you're in the habit of trying to exit the shell by
> >> closing the terminal window, which causes the shell to be killed by SIGHUP
> >> (I think, maybe SIGTERM), the history will not be saved.
> >
> > That will cause a lot of bugreports. Just a question: could an atexit()
> > handler an option or an other way the bash could make use use an extra
> > (sig)longjmp()/(sig)setjmp() after increasing an atomic control variable
> > in the signal handlers for SIGHUP/SIGTERM to run all things done short
> > before exit.
>
> The signal handling is already split up between a handler and a function
> that does the processing when it's `safe'. The problem is that there are
> some signals that have to be handled immediately because it's really not
> possible to continue after receiving them (e.g., SIGSEGV), and some cases
> where you have to handle the signal immediately because you're not in a
> position to wait until a safe time (e.g., when reading input from the
> terminal using read(2)). This is the latter case.
>
> I might be able to finesse this particular case based on the state that
> readline exports to the calling application. Another option is to take
> advantage of the fact that bash installs the SIGHUP handler without the
> SA_RESTART flag, but that requires more extensive changes.
Does this mean that the attached patch could also not work
on some systems? Or does this interfere with the readline
library?
That would be a problem as I'm pretty sure that most users
will see this a major bug. Even sysadmins will open a bug
as a simple shutdown will miss their last few command lines.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- shell.c
+++ shell.c 2011-03-08 16:46:50.201047812 +
@@ -261,6 +261,9 @@ static const struct {
{ (char *)0x0, Int, (int *)0x0, (char **)0x0 }
};
+volatile procenv_t terminating_now;
+volatile sig_atomic_t jump_with_sig;
+
/* These are extern so execute_simple_command can set them, and then
longjmp back to main to execute a shell script, instead of calling
main () again and resulting in indefinite, possibly fatal, stack
@@ -379,6 +382,20 @@ main (argc, argv, env)
if (code)
exit (2);
+ /* Catch signals here */
+ if (setjmp (terminating_now))
+{
+ int sig = jump_with_sig;
+ terminating_signal = 0; /* keep macro from re-testing true. */
+ run_exit_trap ();
+ if (interactive_shell && sig != SIGABRT)
+ maybe_save_shell_history ();
+ set_signal_handler (sig, SIG_DFL);
+ kill (getpid (), sig);
+ _exit(0);
+}
+ jump_with_sig = 0;
+
xtrace_init ();
#if defined (USING_BASH_MALLOC) && defined (DEBUG) && !defined (DISABLE_MALLOC_WRAPPERS)
--- sig.c
+++ sig.c 2011-03-08 16:48:26.707926125 +
@@ -503,10 +503,6 @@ termsig_sighandler (sig)
/* XXX - should this also trigger when interrupt_immediately is set? */
if (terminate_immediately)
{
-#if defined (HISTORY)
- /* XXX - will inhibit history file being written */
- history_lines_this_session = 0;
-#endif
terminate_immediately = 0;
termsig_handler (sig);
}
@@ -514,6 +510,9 @@ termsig_sighandler (sig)
SIGRETURN (0);
}
+extern volatile procenv_t terminating_now;
+extern volatile sig_atomic_t jump_with_sig;
+
void
termsig_handler (sig)
int sig;
@@ -551,9 +550,10 @@ termsig_handler (sig)
loop_level = continuing = breaking = funcnest = 0;
executing_list = comsub_ignore_return = return_catch_flag = 0;
- run_exit_trap ();
- set_signal_handler (sig, SIG_DFL);
- kill (getpid (), sig);
+ terminating_signal = 0; /* keep macro from re-testing true. */
+
+ jump_with_sig = sig;
+ longjmp(terminating_now, 1);
}
/* What we really do when SIGINT occurs. */
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Tue, Mar 08, 2011 at 03:07:13PM +0100, Roman Rakus wrote: > On 03/08/2011 12:32 PM, Dr. Werner Fink wrote: > >Something like the attached patch. > > > Seems it doesn't work. I have applied your patch, run that bash in > gnome-terminal, close the terminal. In gdb I set a break to atexit() > and maybe_save_shell_history() functions. Bash receives SIGHUP, I say > continue, bash again receives SIGHUP, again continue and bash ends. > gdb is saying: Program terminated with signal SIGHUP, Hangup. > > In man page of atexit: > NOTES >Functions registered using atexit() (and on_exit(3)) are not > called if >a process terminates abnormally because of the delivery of a signal. > > so I guess it won't work. I'm aware of this ... but here is what I see: werner/bash> xterm -e bash -l [switch over to new xterm] werner@boole:/usr/src/werner/bash> echo $BASH_VERSION 4.2.7(1)-release werner@boole:/usr/src/werner/bash> echo ooo ooo [hangup due closing xterm] werner/bash> bash werner@boole:/usr/src/werner/bash> echo ooo ... it seems to work here. If it does not work for you, you may try to add the line int maybe_append_history (char *filename) __attribute__((destructor(1))); before the definition of maybe_append_history() in bash-4.2/bashhist.c Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Tue, Mar 08, 2011 at 11:29:22AM +0100, Werner Fink wrote:
> On Mon, Mar 07, 2011 at 10:22:55PM -0500, Chet Ramey wrote:
> >
> > One thing that has changed is that an interactive shell will no longer
> > attempt to write the history file if it's killed by a signal, since that
> > causes many functions to be executed that are not safe to call from a
> > signal handler. If you're in the habit of trying to exit the shell by
> > closing the terminal window, which causes the shell to be killed by SIGHUP
> > (I think, maybe SIGTERM), the history will not be saved.
>
> That will cause a lot of bugreports. Just a question: could an atexit()
> handler an option or an other way the bash could make use use an extra
> (sig)longjmp()/(sig)setjmp() after increasing an atomic control variable
> in the signal handlers for SIGHUP/SIGTERM to run all things done short
> before exit.
Something like the attached patch.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- config.h.in
+++ config.h.in 2011-03-08 11:18:00.139925937 +
@@ -530,6 +530,9 @@
/* Define if you have the asprintf function. */
#undef HAVE_ASPRINTF
+/* Define if you have the ATEXIT function. */
+#undef HAVE_ATEXIT
+
/* Define if you have the bcopy function. */
#undef HAVE_BCOPY
--- configure
+++ configure 2011-03-08 11:20:57.780426177 +
@@ -13497,7 +13497,7 @@ done
-for ac_func in bcopy bzero confstr faccessat fnmatch \
+for ac_func in atexit bcopy bzero confstr faccessat fnmatch \
getaddrinfo gethostbyname getservbyname getservent inet_aton \
memmove pathconf putenv raise regcomp regexec \
setenv setlinebuf setlocale setvbuf siginterrupt strchr \
--- configure.in
+++ configure.in 2011-03-08 11:20:46.020641745 +
@@ -727,7 +727,7 @@ AC_CHECK_FUNCS(dup2 eaccess fcntl getdta
AC_REPLACE_FUNCS(rename)
dnl checks for c library functions
-AC_CHECK_FUNCS(bcopy bzero confstr faccessat fnmatch \
+AC_CHECK_FUNCS(atexit bcopy bzero confstr faccessat fnmatch \
getaddrinfo gethostbyname getservbyname getservent inet_aton \
memmove pathconf putenv raise regcomp regexec \
setenv setlinebuf setlocale setvbuf siginterrupt strchr \
--- sig.c
+++ sig.c 2011-03-08 11:32:29.067927069 +
@@ -292,6 +292,11 @@ initialize_terminating_signals ()
#endif /* !HAVE_POSIX_SIGNALS */
+#if defined (HISTORY) && defined (HAVE_ATEXIT)
+ if (interactive_shell)
+atexit(maybe_save_shell_history);
+#endif /* HISTORY && HAVE_ATEXIT */
+
termsigs_initialized = 1;
}
@@ -504,8 +509,11 @@ termsig_sighandler (sig)
if (terminate_immediately)
{
#if defined (HISTORY)
- /* XXX - will inhibit history file being written */
- history_lines_this_session = 0;
+# if defined (HAVE_ATEXIT)
+ if (sig == SIGABRT)
+# endif
+ /* XXX - will inhibit history file being written */
+ history_lines_this_session = 0;
#endif
terminate_immediately = 0;
termsig_handler (sig);
@@ -532,10 +540,10 @@ termsig_handler (sig)
if (sig == SIGINT && signal_is_trapped (SIGINT))
run_interrupt_trap ();
-#if defined (HISTORY)
+#if defined (HISTORY) && ! defined (HAVE_ATEXIT)
if (interactive_shell && sig != SIGABRT)
maybe_save_shell_history ();
-#endif /* HISTORY */
+#endif /* HISTORY && ! HAVE_ATEXIT */
#if defined (JOB_CONTROL)
if (sig == SIGHUP && (interactive || (subshell_environment & (SUBSHELL_COMSUB|SUBSHELL_PROCSUB
Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
On Mon, Mar 07, 2011 at 10:22:55PM -0500, Chet Ramey wrote: > On 3/6/11 2:53 PM, Doug McMahon wrote: > > with the current bash used in ubuntu 11.04 there no longer is a > > ~/.bash_history created > > If there is an existing ~/.bash_history in place or one is inadvertently > > created, *see below, then it will not be written to > > Demonstrably false: > > (1)$ ./bash > (2)$ HISTFILE=history > (2)$ echo $BASH_VERSION > 4.2.7(3)-maint > (2)$ echo a > a > (2)$ exit > exit > (1)$ cat history > HISTFILE=history > echo $BASH_VERSION > echo a > exit > > One thing that has changed is that an interactive shell will no longer > attempt to write the history file if it's killed by a signal, since that > causes many functions to be executed that are not safe to call from a > signal handler. If you're in the habit of trying to exit the shell by > closing the terminal window, which causes the shell to be killed by SIGHUP > (I think, maybe SIGTERM), the history will not be saved. That will cause a lot of bugreports. Just a question: could an atexit() handler an option or an other way the bash could make use use an extra (sig)longjmp()/(sig)setjmp() after increasing an atomic control variable in the signal handlers for SIGHUP/SIGTERM to run all things done short before exit. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] Fix testsuite errors due to shell quoted parameter expansion issue.
On Tue, Aug 03, 2010 at 02:55:36PM -0600, Eric Blake wrote:
>
> And meanwhile, I found a ksh93 parsing bug (don't know where to report
> that):
>
> $ ksh -c 'a(){ echo hi; }; a'
> ksh: syntax error at line 1: `}' unexpected
> $ ksh -c 'a() { echo hi; }; a'
> hi
> $ bash -c 'a(){ echo hi; }; a'
> hi
> $ /bin/sh -c 'a(){ echo hi; }; a'
> hi
>
> ksh is the only shell that requires a space between the ) and {, even
> though the ) is a metacharacter and should not need trailing space (even
> Solaris /bin/sh got that right).
Just talk with Michal Hlavinka
for this as he uses the ksh/ast developers mailing list.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] [bash-bug] PIPESTATUS always returns only a single element
On Fri, Aug 13, 2010 at 12:18:23PM +0200, Werner Fink wrote:
> On Thu, Aug 12, 2010 at 05:37:55PM -0500, lstee...@gmail.com wrote:
> > #!/bin/bash
> > #
> > # A script to test PIPESTATUS and pipefail
> > #
> > echo " cmd: set +o pipefail"
> > echo " pipe: ps -ef 2>&1 | grep "^\$USR" >/dev/null"
> > set +o pipefail
> > ps -ef 2>&1 | grep "^$USR" >/dev/null
> > echo "expect: PIPESTATUS = 1 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]}
> > \$? = $?"
> > echo
> > echo " cmd: set -o pipefail"
> > echo " pipe: ps -ef 2>&1 | grep "^\$USR" >/dev/null"
> > set -o pipefail
> > ps -ef 2>&1 | grep "^$USR" >/dev/null
> > echo "expect: PIPESTATUS = 1 0 \$? = 1; got: PIPESTATUS = ${PIPESTATUS[*]}
> > \$? = $?"
> > echo
> > echo " pipe: ps aux 2>&1 | grep "^\$USER" >/dev/null"
> > ps aux 2>&1 | grep "^$USER" >/dev/null
> > echo "expect: PIPESTATUS = 0 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]}
> > \$? = $?"
> > echo "expect: PIPESTATUS = 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]}
> > \$? = $?"
> > #
> > # End of script
> >
> > None of the 'got' results 'expect'ing multiple PIPESTATUS results work.
>
> Question: could it be that you're using the bash from
> http://download.opensuse.org/repositories/shells/ or
> http://download.opensuse.org/factory/ ?
>
> Then you may see a side effect of the patch enabling that a pipe uses
> only subshells left from that last pipe symbol. This makes things
> work like
>
> bash> echo 1 2 | read a b; echo $a $b
> 1 2
>
> ... please report such problems on the channels for opensuse.org.
>
> Sorry Chet for the noise
The attached patch should do a better job, nevertheless IMHO there
could be a better solution. This could require some more work
on the COMMAND API to avoid things like
add_process((char*)0, getpid());
in execute_cmd.c, also the addjstatus() function is more like
a workaround to get the status back into the JOB/PROCESS API.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- command.h
+++ command.h 2010-08-13 16:48:35.739125676 +0200
@@ -168,6 +168,7 @@ typedef struct element {
#define CMD_STDIN_REDIR 0x400 /* async command needs implicit flags |= CMD_IGNORE_RETURN;
+
+ begin_unwind_frame ("pipe-file-descriptors");
+ lstdin = -1;
+#if 1
+ if (!asynchronous && pipe_out == NO_PIPE && prev > 0
+ && cmd->type != cm_subshell && ((cmd->flags & CMD_WANT_SUBSHELL) == 0))
+{
+ lstdin = move_to_high_fd(0, 0, 255);
+ if (lstdin > 0)
+ {
+ dup2(prev, 0);
+ close(prev);
+ prev = NO_PIPE;
+ cmd->flags |= CMD_SYNC_PIPE;
+ add_process((char*)0, getpid());
+ stop_pipeline (0, cmd);
+ add_unwind_protect (restore_stdin, lstdin);
+ }
+}
+#endif
+ if (prev >= 0)
+add_unwind_protect (close, prev);
+
exec_result = execute_command_internal (cmd, asynchronous, prev, pipe_out, fds_to_close);
+ if (lstdin > 0)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
if (prev >= 0)
close (prev);
+ discard_unwind_frame ("pipe-file-descriptors");
+
#if defined (JOB_CONTROL)
UNBLOCK_CHILD (oset);
#endif
+ if (cmd->flags & CMD_SYNC_PIPE)
+{
+ addjstatus(cmd, exec_result);
+ cmd->flags &= ~CMD_SYNC_PIPE;
+}
+
QUIT;
return (exec_result);
}
--- jobs.c
+++ jobs.c 2010-08-16 15:48:19.479125702 +0200
@@ -260,7 +260,6 @@ static int processes_in_job __P((int));
static void realloc_jobs_list __P((void));
static int compact_jobs_list __P((int));
static int discard_pipeline __P((PROCESS *));
-static void add_process __P((char *, pid_t));
static void print_pipeline __P((PROCESS *, int, int, FILE *));
static void pretty_print_job __P((int, int, FILE *));
static void set_current_job __P((int));
@@ -1065,7 +1064,7 @@ nohup_job (job_index)
if (js.j_jobslots == 0)
return;
- if (temp = jobs[job_index])
+ if ((temp = jobs[job_index]))
temp->flags |= J_NOHUP;
}
@@ -1095,7 +1094,7 @@ discard_pipeline (chain)
/* Add this process to the chain being built in the_pipeline.
NAME is the command string that will be exec'ed later.
PID is the process id of the child. */
-static void
+void
add_process (name, pid)
char *name;
pid_t pid;
@@ -3396,6 +3395,34 @@ setjstatus (j)
#endif
}
+
+void
+addjstatus(COMMAND *deferred, int status)
+{
+#if defined (ARRAY_VARS)
+ int i;
+ JOB *j;
+ for (j = jobs[(i = 0)]; j && j->deferred != deferred; j = jobs[(++i)])
+;
+ if (!j || !j->deferred)
+return;
+ j->deferred = (COMMAND*)0;
+ if (status)
+{
+ PROCESS *p, *l;
+ p = j->pipe;
+ do
+ {
+ l = p;
+ p = p->next;
+ }
+ while (p != j->pipe);
+ l->status = status << 8;
+}
+ setjstatus(i);
+#endif
+}
+
void
run_sigchld_trap (nchild)
int nchild;
--- jobs.h
+++ jobs.h 2010-08-16 15:47:22.463125472 +0200
@@ -177,6 +177,8 @@ extern void save_pipeline __P((int));
extern void restore_pipeline __P((int));
extern void start_pip
Re: [bash-bug] PIPESTATUS always returns only a single element
On Thu, Aug 12, 2010 at 05:37:55PM -0500, lstee...@gmail.com wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc -I/usr/src/packages/BUILD/bash-4.1
> -L/usr/src/packages/BUILD/bash-4.1/../readline-6.1
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu'
> -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g
> -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum
> -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe
> -fprofile-use
> uname output: Linux russte14 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16
> 21:25:39 +0100 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-suse-linux-gnu
>
> Bash Version: 4.1
> Patch Level: 7
> Release Status: release
>
> Description:
> PIPESTATUS never shows more than 1 array element after executing a
> multiple command pipe
>
> Repeat-By:
> Execute the following script:
>
> #!/bin/bash
> #
> # A script to test PIPESTATUS and pipefail
> #
> echo " cmd: set +o pipefail"
> echo " pipe: ps -ef 2>&1 | grep "^\$USR" >/dev/null"
> set +o pipefail
> ps -ef 2>&1 | grep "^$USR" >/dev/null
> echo "expect: PIPESTATUS = 1 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]}
> \$? = $?"
> echo
> echo " cmd: set -o pipefail"
> echo " pipe: ps -ef 2>&1 | grep "^\$USR" >/dev/null"
> set -o pipefail
> ps -ef 2>&1 | grep "^$USR" >/dev/null
> echo "expect: PIPESTATUS = 1 0 \$? = 1; got: PIPESTATUS = ${PIPESTATUS[*]}
> \$? = $?"
> echo
> echo " pipe: ps aux 2>&1 | grep "^\$USER" >/dev/null"
> ps aux 2>&1 | grep "^$USER" >/dev/null
> echo "expect: PIPESTATUS = 0 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]}
> \$? = $?"
> echo "expect: PIPESTATUS = 0 \$? = 0; got: PIPESTATUS = ${PIPESTATUS[*]} \$?
> = $?"
> #
> # End of script
>
> None of the 'got' results 'expect'ing multiple PIPESTATUS results work.
Question: could it be that you're using the bash from
http://download.opensuse.org/repositories/shells/ or
http://download.opensuse.org/factory/ ?
Then you may see a side effect of the patch enabling that a pipe uses
only subshells left from that last pipe symbol. This makes things
work like
bash> echo 1 2 | read a b; echo $a $b
1 2
... please report such problems on the channels for opensuse.org.
Sorry Chet for the noise
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] parsing error with heredoc and command substitution
On Tue, Jul 13, 2010 at 01:51:31PM -0400, Alex Khesin wrote: > Configuration Information: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include > -I../bash/lib -g -O2 -Wall > uname output: Linux alexk 2.6.32-gg173-generic #gg173 SMP Wed Jun 23 > 05:24:15 UTC 2010 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > Bash Version: 4.1 > Patch Level: 5 > Release Status: release > > Description: > > The following script used to work in bash 3.2 but does not work with > bash 4.x (I tried 4.0, 4.1.5, and 4.1.7) > > -- > #!/bin/bash > > a=$(/bin/cat << EOF | wc -l > a > b > EOF > ) > - > > /tmp/bug.sh: line 3: unexpected EOF while looking for matching `)' > /tmp/bug.sh: line 8: syntax error: unexpected end of file > > The following works correctly (changed /bin/cat to cat): > > -- > #!/bin/bash > > a=$(cat << EOF | wc -l > a > b > EOF > ) > - > > and so does this (removed | wc -l): > > -- > #!/bin/bash > > a=$(/bin/cat << EOF > a > b > EOF > ) > - Hmmm ... I would expect that a=$((/bin/cat|wc -l) <
Re: [bash-bug] A note for read builtin
On Thu, Jun 24, 2010 at 01:18:25PM -0400, Chet Ramey wrote: > On 6/23/10 6:08 AM, Dr. Werner Fink wrote: > > > Yet an other version of the patch to avoid trouble with the > > coproc builtin tested out in tests/coproc.tests. There is one > > difference more with tests/redir.tests at > > Thanks, this is a great start. There's still more work to be done with > bookkeeping, and it won't work with job control, but it should get a > large part of the way there for non-interactive shells. Yep I've stumbled across a hanging bash if used interactive. It seems that adding stop_pipeline (0, (COMMAND *)NULL); after prev = NO_PIPE; at least does avoid this. See the patch in my last mail with the message ID <20100624073708.ga13...@boole.suse.de>. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] A note for read builtin
On Wed, Jun 23, 2010 at 12:08:20PM +0200, Werner Fink wrote:
>
> Yet an other version of the patch to avoid trouble with the
> coproc builtin tested out in tests/coproc.tests. There is one
> difference more with tests/redir.tests at
>
> exit 3 | $EXIT > $TMPDIR/null-redir-e
> echo $? -- ${pipestat...@]}
> testf $TMPDIR/null-redir-e
>
> exit 4 | > $TMPDIR/null-redir-f
> echo $? -- ${pipestat...@]}
> testf $TMPDIR/null-redir-f
>
> which now reports
>
> 0 -- 3 0
> 0 -- 4 0
>
> instead of
>
> 0 -- 0
> 0 -- 0
>
> but seems to me ok.
One change more is required for an interactive bash
that is that building pipes used for pgrps synchronization
should be stop for the last command as this last one
is now the parent its self.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- execute_cmd.c
+++ execute_cmd.c 2010-06-24 09:18:46.858925084 +0200
@@ -1525,7 +1525,7 @@ static struct cpelement *cpl_search __P(
static struct cpelement *cpl_searchbyname __P((char *));
static void cpl_prune __P((void));
-Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0 };
+Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0, 0, 0 };
cplist_t coproc_list = {0, 0, 0};
@@ -2047,13 +2047,19 @@ execute_coproc (command, pipe_in, pipe_o
}
#endif
+static void restore_stdin(int lstdin)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
static int
execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
COMMAND *command;
int asynchronous, pipe_in, pipe_out;
struct fd_bitmap *fds_to_close;
{
- int prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
+ int lstdin, prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
COMMAND *cmd;
struct fd_bitmap *fd_bitmap;
@@ -2148,11 +2154,37 @@ execute_pipeline (command, asynchronous,
/* Now execute the rightmost command in the pipeline. */
if (ignore_return && cmd)
cmd->flags |= CMD_IGNORE_RETURN;
+
+ begin_unwind_frame ("pipe-file-descriptors");
+ lstdin = -1;
+ if (!asynchronous && pipe_out == NO_PIPE && prev > 0)
+{
+ lstdin = move_to_high_fd(0, 0, 255);
+ if (lstdin > 0)
+ {
+ dup2(prev, 0);
+ close(prev);
+ prev = NO_PIPE;
+ stop_pipeline (0, (COMMAND *)NULL);
+ add_unwind_protect (restore_stdin, lstdin);
+ }
+}
+ if (prev >= 0)
+add_unwind_protect (close, prev);
+
exec_result = execute_command_internal (cmd, asynchronous, prev, pipe_out, fds_to_close);
+ if (lstdin > 0)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
if (prev >= 0)
close (prev);
+ discard_unwind_frame ("pipe-file-descriptors");
+
#if defined (JOB_CONTROL)
UNBLOCK_CHILD (oset);
#endif
Re: [bash-bug] A note for read builtin
On Wed, Jun 23, 2010 at 10:00:12AM +0200, Werner Fink wrote:
> On Tue, Jun 22, 2010 at 04:50:54PM -0400, Chet Ramey wrote:
> > On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
> >
> > > as now is visible the last command in the pipe sequence done
> > > in the bash is a real sub process whereas in the ksh it is not.
> > >
> > > The question rises: Why does the bash require a sub peocess/shell
> > > for the final command of a pipe sequence.
> >
> > It's an implementation decision: the code as it exists today is more
> > straightforward. Since Posix requires that all commands in a pipeline
> > be executed in a subshell environment, though it allows the ksh behavior
> > as an extension, there's been no requirement to change it.
> >
> > If anyone would like to take a shot at changing the code to not fork when
> > executing a command with a pipe for stdin, I'd be glad to take a look at
> > the result.
>
> OK ... after a deeper look into execute_cmd.c I'd like to suggest
> something like in the attachment. Anyone around with a better
> solution? Maybe there is a way to emulate the first pipe commands
> as a named fifo for the last element of the pipe which may avoid
> moving stdin around. Anyway the patch makes things like:
>
> bash/bash-4.1> ./bash -c 'echo a b | while read x y; do a=$x b=$y; done;
> echo $a $b'
> a b
> bash/bash-4.1> ./bash -c 'echo a b | read a b ; echo $a $b'
> a b
>
> work. The change of sh_coproc is simply to avoid a (correct)
> compiler warning.
Yet an other version of the patch to avoid trouble with the
coproc builtin tested out in tests/coproc.tests. There is one
difference more with tests/redir.tests at
exit 3 | $EXIT > $TMPDIR/null-redir-e
echo $? -- ${pipestat...@]}
testf $TMPDIR/null-redir-e
exit 4 | > $TMPDIR/null-redir-f
echo $? -- ${pipestat...@]}
testf $TMPDIR/null-redir-f
which now reports
0 -- 3 0
0 -- 4 0
instead of
0 -- 0
0 -- 0
but seems to me ok.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- execute_cmd.c
+++ execute_cmd.c 2010-06-23 12:00:06.870925148 +0200
@@ -1525,7 +1525,7 @@ static struct cpelement *cpl_search __P(
static struct cpelement *cpl_searchbyname __P((char *));
static void cpl_prune __P((void));
-Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0 };
+Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0, 0, 0 };
cplist_t coproc_list = {0, 0, 0};
@@ -2047,13 +2047,19 @@ execute_coproc (command, pipe_in, pipe_o
}
#endif
+static void restore_stdin(int lstdin)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
static int
execute_pipeline (command, asynchronous, pipe_in, pipe_out, fds_to_close)
COMMAND *command;
int asynchronous, pipe_in, pipe_out;
struct fd_bitmap *fds_to_close;
{
- int prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
+ int lstdin, prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
COMMAND *cmd;
struct fd_bitmap *fd_bitmap;
@@ -2148,11 +2154,36 @@ execute_pipeline (command, asynchronous,
/* Now execute the rightmost command in the pipeline. */
if (ignore_return && cmd)
cmd->flags |= CMD_IGNORE_RETURN;
+
+ begin_unwind_frame ("pipe-file-descriptors");
+ lstdin = -1;
+ if (!asynchronous && pipe_out == NO_PIPE && prev > 0)
+{
+ lstdin = move_to_high_fd(0, 0, 255);
+ if (lstdin > 0)
+ {
+ dup2(prev, 0);
+ close(prev);
+ prev = NO_PIPE;
+ add_unwind_protect (restore_stdin, lstdin);
+ }
+}
+ if (prev >= 0)
+add_unwind_protect (close, prev);
+
exec_result = execute_command_internal (cmd, asynchronous, prev, pipe_out, fds_to_close);
+ if (lstdin > 0)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
if (prev >= 0)
close (prev);
+ discard_unwind_frame ("pipe-file-descriptors");
+
#if defined (JOB_CONTROL)
UNBLOCK_CHILD (oset);
#endif
Re: A note for read builtin
On Tue, Jun 22, 2010 at 04:50:54PM -0400, Chet Ramey wrote:
> On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
>
> > as now is visible the last command in the pipe sequence done
> > in the bash is a real sub process whereas in the ksh it is not.
> >
> > The question rises: Why does the bash require a sub peocess/shell
> > for the final command of a pipe sequence.
>
> It's an implementation decision: the code as it exists today is more
> straightforward. Since Posix requires that all commands in a pipeline
> be executed in a subshell environment, though it allows the ksh behavior
> as an extension, there's been no requirement to change it.
>
> If anyone would like to take a shot at changing the code to not fork when
> executing a command with a pipe for stdin, I'd be glad to take a look at
> the result.
OK ... after a deeper look into execute_cmd.c I'd like to suggest
something like in the attachment. Anyone around with a better
solution? Maybe there is a way to emulate the first pipe commands
as a named fifo for the last element of the pipe which may avoid
moving stdin around. Anyway the patch makes things like:
bash/bash-4.1> ./bash -c 'echo a b | while read x y; do a=$x b=$y; done; echo
$a $b'
a b
bash/bash-4.1> ./bash -c 'echo a b | read a b ; echo $a $b'
a b
work. The change of sh_coproc is simply to avoid a (correct)
compiler warning.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--- execute_cmd.c
+++ execute_cmd.c 2010-06-23 09:58:23.119134909 +0200
@@ -1525,7 +1525,7 @@ static struct cpelement *cpl_search __P(
static struct cpelement *cpl_searchbyname __P((char *));
static void cpl_prune __P((void));
-Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0 };
+Coproc sh_coproc = { 0, NO_PID, -1, -1, 0, 0, 0, 0 };
cplist_t coproc_list = {0, 0, 0};
@@ -2053,7 +2053,7 @@ execute_pipeline (command, asynchronous,
int asynchronous, pipe_in, pipe_out;
struct fd_bitmap *fds_to_close;
{
- int prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
+ int lstdin, prev, fildes[2], new_bitmap_size, dummyfd, ignore_return, exec_result;
COMMAND *cmd;
struct fd_bitmap *fd_bitmap;
@@ -2148,8 +2148,26 @@ execute_pipeline (command, asynchronous,
/* Now execute the rightmost command in the pipeline. */
if (ignore_return && cmd)
cmd->flags |= CMD_IGNORE_RETURN;
+
+ lstdin = -1;
+ if (!asynchronous && pipe_out == NO_PIPE && prev > 0)
+{
+ lstdin = move_to_high_fd(0, 0, 64);
+ if (lstdin > 0)
+ {
+ dup2(prev, 0);
+ prev = NO_PIPE;
+ }
+}
+
exec_result = execute_command_internal (cmd, asynchronous, prev, pipe_out, fds_to_close);
+ if (lstdin > 0)
+{
+ dup2(lstdin, 0);
+ close(lstdin);
+}
+
if (prev >= 0)
close (prev);
A note for read builtin
Just a remark about the sub shell usage in bash in comparision to
ksh. Let's try:
strace -f -o bash.strace bash -c 'echo a b | read a b'
and grep about execve, clone, write on stdout, read from stdin:
> grep -E 'execve|clone|write\(1|read\(0' bash.strace
17183 execve("/bin/bash", ["bash", "-c", "echo a b | read a b"], [/* 99
vars */]) = 0
17183 clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7d61708)
= 17184
17183 clone(
17183 <... clone resumed> child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7d61708)
= 17185
17184 write(1, "a b\n", 4
17185 read(0, "a", 1) = 1
17185 read(0, " ", 1) = 1
17185 read(0, "b", 1) = 1
17185 read(0, "\n", 1) = 1
and now the same with the Korn shell
strace -f -o ksh.strace ksh -c 'echo a b | read a b'
> grep -E 'execve|clone|write\(1|read\(0' ksh.strace | sed 's/^//'
17198 execve("/bin/ksh", ["ksh", "-c", "echo a b | read a b"], [/* 99 vars
*/]) = 0
17198 clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7bb3918)
= 17199
17199 write(1, "a b\n", 4) = 4
17198 read(0,
as now is visible the last command in the pipe sequence done
in the bash is a real sub process whereas in the ksh it is not.
The question rises: Why does the bash require a sub peocess/shell
for the final command of a pipe sequence.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
On Tue, Apr 06, 2010 at 08:35:13AM -0400, Greg Wooledge wrote: > On Tue, Apr 06, 2010 at 02:21:05PM +0200, Roman Rakus wrote: > > >>$((2 ** 63 / -1)) > > > I can reproduce it in 4.1.2(1)-release and 4.0.23(1)-release on x86_64 > > GNU/Linux. I didn't try on bash 3.2. > > cyclops:~$ uname -a; echo $BASH_VERSION > OpenBSD cyclops.wooledge.org 4.6 GENERIC.MP#81 amd64 > 4.0.24(1)-release > cyclops:~$ echo $((2 ** 63 / -1)) > Connection to cyclops closed. > griffon:~$ > > An amd64-specific bug, then? (The Linux box I tested on earlier is i386, > and the HP-UX box is PA-RISC 2.0.) On x86_64 I see: ~> echo $((2 ** 63 / -1)) Floating exception whereas on i686 ~> echo $((2 ** 63 / -1)) -9223372036854775808 ... both GNU/Linux. On x86_64 the gdb shows: Program received signal SIGFPE, Arithmetic exception. 0x00462cd5 in exp2 () at expr.c:761 761 val1 /= val2; (gdb) print val1 $1 = -9223372036854775808 (gdb) print val2 $2 = -1 which is strange. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] Crash on completion
On Tue, Mar 09, 2010 at 02:51:18PM +0100, Roman Rakus wrote:
>
> The bash segfaults on the line `while (val =
> glob_matches[local_index++])', because glob_matches is pointer to
> NULL. I have add the check for this null. But this is most likely
> not the right patch.
> RR
> diff -up bash-4.1/bashline.c.crash bash-4.1/bashline.c
> --- bash-4.1/bashline.c.crash 2010-03-09 14:26:06.0 +0100
> +++ bash-4.1/bashline.c 2010-03-09 14:46:10.0 +0100
> @@ -1700,7 +1700,8 @@ globword:
> return ((char *)NULL);
> }
>
> - while (val = glob_matches[local_index++])
> + /* make sure glob_matches is not NULL */
> + while (glob_matches && (val = glob_matches[local_index++]))
> {
> if (executable_or_directory (val))
> {
Maybe something like:
--- bashline.c
+++ bashline.c 2010-03-09 14:11:27.612626475 +
@@ -1700,6 +1700,13 @@ globword:
return ((char *)NULL);
}
+ if (GLOB_FAILED (glob_matches) || glob_matches == 0)
+ {
+ glob_ignore_case = old_glob_ignore_case;
+ glob_matches = (char **)NULL;
+ return ((char *)NULL);
+ }
+
while (val = glob_matches[local_index++])
{
if (executable_or_directory (val))
as this also include the check found for (state == 0) case
a few lines above the affected line?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] bash accepts script with incorrect syntax and goes into infinite loop
On Fri, Oct 09, 2009 at 11:46:16AM +0100, Dave B wrote: > On Friday 09 October 2009, Pierre Gaston wrote: > > Uhm, on a more accurate reading you're probably right. The POSIX syntax for > while is > > while compound-list-1 do > compound-list-2 > done > > And "read NAME; echo NAME=$NAME" is a compound-list. So I was deceived by the > formatting, I think you are right. Thanks for correcting me. I also agree ( even if I'm the reporter :) now I can close the bug reprort here, thanks. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Bash loadable plugins ... minimal header file?
Hi, AFAICS from examples/loadables/ a lot of headers are readed by the compiler which requires - beside the bash and the readline library - an further package (rpm/deb) bash-devel for including all those headers ... beside this the Makefiles do not install any of them. Therefore my question: how does a minimal header looks like? It should include the API for the argument handling and clearly the declarations found in builtins.h after the includes. My wish is to have a few minimal header files without installing nearly all header files. Comments, hints? Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: [bash-bug] contents of whole arrays dissapears leaving while read loop
On Thu, Mar 26, 2009 at 10:38:20AM +0100, Jan Schampera wrote: > Lennart Schultz wrote: > > > In the construct > > cat file|while read line > > do > > done > > the content of any arry assignments in the loop dissapears leaving the loop: > > This is logic, since every part of the pipe runs in an own subshell (the > first one runs in the "current shell"). This behaviour is also *not* > limited to arrays. > > This is not a bug, this is a consequence of Bash's design. Yep ... nevertheless a side mark: ksh can do ;) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
bash $'foo' quoting problem
Hi,
the bash-3.1.5 has a problem with quoting which leads to
a different output of
echo $(set -- $'a b'; echo $#)
and
echo "$(set -- $'a b'; echo $#)"
The patch below fix this problem.
Werner
*** parse.y
--- parse.y Tue Jan 10 11:36:59 2006
***
*** 2842,2848
ttrans = ansiexpand (nestret, 0, nestlen - 1, &ttranslen);
xfree (nestret);
! if ((rflags & P_DQUOTE) == 0)
{
nestret = sh_single_quote (ttrans);
free (ttrans);
--- 2842,2848
ttrans = ansiexpand (nestret, 0, nestlen - 1, &ttranslen);
xfree (nestret);
! if (extended_quote || (rflags & P_DQUOTE) == 0)
{
nestret = sh_single_quote (ttrans);
free (ttrans);
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
