Re: Bash Bug - Incorrect Printing of Escaped Characters

Hi Grisha, I didn’t know to look there (I’m still pretty new to the Bash source). Thanks, this is exciting! Best, Seth On Jan 16, 2024, at 12:18 PM, Grisha Levit wrote:  On Tue, Jan 16, 2024, 11:01 Seth Sabar <[1]sethsa...@gmail.com> wrote: Are you planni

Re: Bash Bug - Incorrect Printing of Escaped Characters

On Tue, Jan 16, 2024, 11:01 Seth Sabar wrote: > Are you planning on releasing a patch for this? If you'd like me to try to > prepare a patch, I'd appreciate some guidance around the various > dequote_... functions in subst.c. Thanks! > Hi Seth, Chet has committed a fix for this in the devel bran

Re: Bash Bug - Incorrect Printing of Escaped Characters

Are you planning on releasing a patch for this? If you'd like me to try to prepare a patch, I'd appreciate some guidance around the various dequote_... functions in subst.c. Thanks! Best, Seth On Wed, Dec 27, 2023 at 1:03 PM Chet Ramey wrote: > On 12/25/23 5:00 PM, Seth Sabar wrote: > > Hi all,

Re: Bash Bug - Incorrect Printing of Escaped Characters

On 12/25/23 5:00 PM, Seth Sabar wrote: Hi all, I'm reaching out to report what I believe to be a bug with the *--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the utf-8 character */001* as an escape character. However, when using the pretty-print feature in Bash, this doesn'

Re: Bash Bug - Incorrect Printing of Escaped Characters

On Mon, Dec 25, 2023 at 05:00:37PM -0500, Seth Sabar wrote: > I'm reaching out to report what I believe to be a bug with the > *--pretty-print* feature in bash-5.2. Tangentially, this option doesn't seem to be documented outside of "bash --help": $ git clone https://git.savannah.gnu.org/git/b

Re: Bash Bug

On Tue, Jun 27, 2023, 07:23 alex xmb ratchev wrote: > > > On Tue, Jun 27, 2023, 04:55 Kaif Khan wrote: > >> Thank you for your response, but my bug is rather very simple and not >> complicated. I am attaching a video to explain the bug. >> > whats the output of declare -p PS0 PS1 PROMPT_COMMAND

Re: Bash Bug

if u modify PS1 , u must enclose escape / color codes in literarly \[ and \] eg PS1=$'\[\e[0;1m\]bold\[\e[0m\] ' and the err u say , looks like u didnt make that proper bind cmd On Mon, Jun 26, 2023, 19:15 Kaif Khan wrote: > >

Re: bash bug about Chinese translation

On 7/27/22 2:59 AM, C. Cicada wrote: > Version : 5.1.16 > OS: Fedora > Problem: under Chinese (both simplified and tradition), bash buildin command > 'type' has traslation mistake in its help file. Hi. Thanks for the report. Please contact the GNU Translation project about translation errors. I

Re: bash bug with root account

On Wed, Jul 10, 2019 at 09:15:14AM -0400, Chet Ramey wrote: > On 7/10/19 4:01 AM, westlake wrote: > > If a normal user types "su -l" and issues this "ls" statement, > This account has the `extglob' shell option enabled. "su -l" gives you a login shell, so this instance of bash is reading /etc/prof

Re: bash bug with root account

On 7/10/19 4:01 AM, westlake wrote: > System: linux 64-bit (debian stable, latest release buster) > Bash version: GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) > > This bug occurs with the root account, > > If a normal user types "su -l" and issues this "ls" statement, > > ls -ld .!(?

Re: bash bug - unexpect file deleted using rm command

On Tue, May 28, 2019 at 04:43:42PM +0200, Andreas Kusalananda Kähäri wrote: > On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAG

Re: bash bug - unexpect file deleted using rm command

On 5/28/19 7:56 AM, r...@minigeek.srve.com wrote: > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > I deleted the file .DS_Store fom a fat32 partition as root. bash > properly warned me and I answered y which deleted that file. > A second different fi

Re: bash bug - unexpect file deleted using rm command

On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTY

Re: Bash bug

You can do: local var; var=$(...); ... $? No need to make the declaration and assignment at the same time.

Re: Bash bug

On Tue, Aug 23, 2016 at 2:34 AM, Weshakie Löwe wrote: > When storing the value of code executed in a subshell the return value is > always 0 if the variable is local. > > Code example: > > A(){ > local return_value="$(bash -c "exit 1")" > echo $? > } > > function A: returns 0 - even though obvi

Re: Bash bug in variable assignment/echo/grep -q

Got it, thanks On Wed, Jun 22, 2016 at 12:21 PM, Chet Ramey wrote: > On 6/21/16 9:35 PM, Roel Van de Paar wrote: > > > Bash Version: 4.2 > > Patch Level: 46 > > Release Status: release > > > > Description: > > DONE=0 at the end of the 'Repeat-By' script - should be 1 ? > > > > Repeat-By:

Re: Bash bug in variable assignment/echo/grep -q

On 6/21/16 9:35 PM, Roel Van de Paar wrote: > Bash Version: 4.2 > Patch Level: 46 > Release Status: release > > Description: > DONE=0 at the end of the 'Repeat-By' script - should be 1 ? > > Repeat-By: > LINE='test'; DONE=0; echo ${LINE} | if grep -q 'test'; then DONE=1; > echo "

Re: bash bug with read -s command

On 12/21/14 3:28 PM, Richard W. Marsden wrote: > steps to produce > > hide cursor > setterm -cursor off > > call the bash built-in read command as follows: silent, wait 1 second, read > 1 character to variable KEY > read -s -t 1 -n 1 KEY > > while the read command is in a loop, control +

Re: bash bug with read -s command

Hey, without checking the source: reset utility from ncurses fixes your term. this one is reproducible. cheers, pg On Sun, Dec 21, 2014 at 9:28 PM, Richard W. Marsden wrote: > steps to produce > > hide cursor > setterm -cursor off > > call the bash built-in read command as follows: sil

Re: Bash "bug" - in "read -e -r var"

On 12/15/14 11:13 AM, Dan Douglas wrote: > Ah ok I thought -e basically negated the effect of -r for some reason but I > guess not (like you can still use \ to escape line continuations without -r it > seems). They're separate but kind of clumsy to use together for line continuations. `read' end

Re: Bash "bug" - in "read -e -r var"

On Monday, December 15, 2014 10:47:29 AM Chet Ramey wrote: > On 12/15/14, 7:11 AM, Dan Douglas wrote: > > > I'm generally interested in what read with (or without) -r combined with -e > > even means. > > I'm not sure what you're driving at. The -e option says how to read the > line; the -r option

Re: Bash "bug" - in "read -e -r var"

On 12/15/14, 7:11 AM, Dan Douglas wrote: > I'm generally interested in what read with (or without) -r combined with -e > even means. I'm not sure what you're driving at. The -e option says how to read the line; the -r option affects how the characters are processed after being read. -- ``The

Re: Bash "bug" - in "read -e -r var"

On 12/15/14, 7:11 AM, Dan Douglas wrote: > I understand that read's now basically useless behavior without -r > was originally there to make using it interactively without a line editor > slightly easier. Ask David Korn, since he originally added options to the read builtin. None of the `pure'

Re: Bash "bug" - in "read -e -r var"

On Sunday, December 14, 2014 04:27:51 PM Chet Ramey wrote: > On 12/13/14 12:06 AM, Daniel A. Gauthier wrote: > > > > If you do a "read -e -r var" in bash, and use tab completion to fill-in > > a filename, it fills in "My\ File\ Name.txt" and that's exactly > > what's read into the variable. The f

Re: Bash "bug" - in "read -e -r var"

On 12/13/14 12:06 AM, Daniel A. Gauthier wrote: > > If you do a "read -e -r var" in bash, and use tab completion to fill-in > a filename, it fills in "My\ File\ Name.txt" and that's exactly > what's read into the variable. The fix is simple, in tab completion, > the text placed into the buffer sh

Re: Bash bug interpolating delete characters

Am 07.05.2012 22:46, schrieb Chet Ramey: > On 5/3/12 5:53 AM, Ruediger Kuhlmann wrote: >> Hi, >> >> please try the following bash script: >> >> a=x >> del="$(echo -e "\\x7f")" >> >> echo "$del${a#x}" | od -ta >> echo "$del ${a#x}" | od -ta >> echo " $del${a#x}" | od -ta >> >> Using bash 3.2, the ou

Re: Bash bug interpolating delete characters

On 5/3/12 5:53 AM, Ruediger Kuhlmann wrote: > Hi, > > please try the following bash script: > > a=x > del="$(echo -e "\\x7f")" > > echo "$del${a#x}" | od -ta > echo "$del ${a#x}" | od -ta > echo " $del${a#x}" | od -ta > > Using bash 3.2, the output is: > > 000 del nl > 002 > 000 d

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

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

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 hist

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

On 3/8/11 1:32 PM, Eric Blake wrote: > Really, the only safe way to handle things like SIGHUP cleanup is to > have the signal handler record that an exception occurred, then have the > main processing loop checking that variable frequently enough to do > cleanup in a reasonable time-frame (possibl

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

On 03/08/2011 11:00 AM, Andreas Schwab wrote: > "Dr. Werner Fink" writes: > >> 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? >>> >>> Sinc

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

"Dr. Werner Fink" writes: > 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 s

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

(03/08/2011 09:19 AM), Roman Rakus wrote: > On 03/08/2011 06:02 PM, Chet Ramey wrote: >> I really wish there was a better solution to the close button problem >> than SIGHUP. > +1, or learn people to exit from shell. Yeah, but what of when your ssh connection goes down (and you're not using screen

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,

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

On 03/08/2011 06:02 PM, Chet Ramey wrote: I really wish there was a better solution to the close button problem than SIGHUP. +1, or learn people to exit from shell. RR

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

On 3/8/11 11:51 AM, Dr. Werner Fink wrote: > 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, sin

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 execu

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

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

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

On 3/8/11 10:10 AM, Dr. Werner Fink wrote: > 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 t

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 m

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

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 conti

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 fun

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,

Re: Bash bug with ints beyond 2147483646

On 11/2/10 3:48 PM, Pete Gregory wrote: > Even with a 64-bit kernel, under bash4.1-2 under ubuntu 10.04, problems exist > with numbers beyond 2147483646. > > Easy duplication method: > echo {2147483640..2147483646} > reports > 2147483640 2147483641 2147483642 2147483643 2147483644 2147483645 214

Re: Bash bug with ints beyond 2147483646

Marc Herbert writes: > #0 __lll_lock_wait_private () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 > #1 0x00323007c138 in _L_lock_9162 () at malloc.c:3503 > #2 0x003230079a32 in __libc_malloc (bytes=215557320320) at malloc.c:3657 > #3 0x004664c3 in xmalloc (by

Re: Bash bug with ints beyond 2147483646

Le 02/11/2010 19:48, Pete Gregory a écrit : > Easy duplication method: > echo {2147483640..2147483646} > reports > 2147483640 2147483641 2147483642 2147483643 2147483644 2147483645 2147483646 > echo {2147483640..2147483647} > dies with a malloc error - At other times I get this error: *** gli

Re: Bash bug with ints beyond 2147483646

Greg Wooledge wrote: On Tue, Nov 02, 2010 at 03:48:49PM -0400, Pete Gregory wrote: echo {2147483640..2147483647} dies with a malloc error In bash 4.1.9 under HP-UX 10.20, it consumes all available CPU until I kill it with SIGKILL. (I suppose there's a chance it might eventually have died due

Re: Bash bug with ints beyond 2147483646

> echo {2147483640..2147483647} > dies with a malloc error I suggest that Linux kids do not try this at home: the OutOfMemory killer killed a few random processes of mine!

Re: Bash bug with ints beyond 2147483646

On Tue, Nov 02, 2010 at 03:48:49PM -0400, Pete Gregory wrote: > echo {2147483640..2147483647} > dies with a malloc error In bash 4.1.9 under HP-UX 10.20, it consumes all available CPU until I kill it with SIGKILL. (I suppose there's a chance it might eventually have died due to malloc errors or w

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' >

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"

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:

Re: [bash-bug] parsing error with heredoc and command substitution

Am 15.07.2010 10:35, schrieb Andreas Schwab: "Dr. Werner Fink" writes: a=$((/bin/cat|wc -l)< Useless subshell. a=$({ /bin/cat | wc -l; }< ...and useless cat: a=$(wc -l

Re: [bash-bug] parsing error with heredoc and command substitution

"Dr. Werner Fink" writes: > a=$((/bin/cat|wc -l) < a > b > EOF > ) Useless subshell. a=$({ /bin/cat | wc -l; } <

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' -DLOCAL

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, t

Re: [bash-bug] A note for read builtin

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

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 $? -- ${pi

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 k

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

On 4/6/10 11:56 AM, Roman Rakus wrote: > On 04/06/2010 05:32 PM, John Reiser wrote: > Program received signal SIGFPE, Arithmetic exception. > 0x00462cd5 in exp2 () at expr.c:761 > 761 val1 /= val2; > (gdb) print val1 > $1 = -9223372036854775808 > (gdb) print val2 >>>

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

On 04/06/2010 05:32 PM, John Reiser wrote: 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. Not at all. Overflow invokes undefined behaviour

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

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. Not at all. Overflow invokes undefined behaviour. But why there is no overflow on 32bit s

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

Roman Rakus writes: > But why there is no overflow on 32bit system? Why do you think so? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

On 04/06/2010 03:59 PM, Andreas Schwab wrote: "Dr. Werner Fink" writes: 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) pri

Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?

"Dr. Werner Fink" writes: > 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. No

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; ech

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/bash

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

Re: [bash-bug] contents of whole arrays dissapears leaving while read loop

Dr. Werner Fink wrote: >> This is not a bug, this is a consequence of Bash's design. > > Yep ... nevertheless a side mark: ksh can do ;) Which is: A consequence of Korn's design ;-) *waves the 80km to Nuremberg* Jan

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 o

Re: Bash Bug: Concatenating String with $'\NNN' Error

I just sent a bug report with the above description; please ignore.. I'm an idiot. There is no error actually my math was bad.

Fwd: Re: Bash bug --- 1st parameter substitued for /InstallShield/ that is passed to the main entry pt of program

Paul, Thk u for the quick response. I hope now this is the correct place to respond to your email regarding my misunderstanding. I'm answering my own raised questions from your response that others might also learn from: Yes my ignorance on the wild character substitution triggered by * and

Re: bash=~ bug or feature

On Thu, 17 May 2007, Bob Proulx wrote: The behavior has been intentionally changed. Please see Bash FAQ item E14. Ok, thanks. I should have read the FAQ first. Thanks, Jeff. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailm

Re: bash=~ bug or feature

> With bash 3.1.17(4)-release > # [[ "abcd" =~ "^a" ]]; echo $? > 0 > > With bash 3.2.17(3)-release > # [[ "abcd" =~ "^a" ]]; echo $? # is this a bug??? > 1 > # [[ "abcd" =~ ^a ]]; echo $? > 0 > > Is this a bug? It is the intended behavior. See question E14 in the latest bash FAQ (reproduced

Re: bash=~ bug or feature

Jeff Chua wrote: > With bash 3.1.17(4)-release > # [[ "abcd" =~ "^a" ]]; echo $? > 0 > > With bash 3.2.17(3)-release > # [[ "abcd" =~ "^a" ]]; echo $? # is this a bug??? > 1 > # [[ "abcd" =~ ^a ]]; echo $? > 0 > > Is this a bug? The behavior has been intentionally changed. Please see Bash FAQ

Re: BASH bug or expected behaviour?

Dean K. Gibson wrote: > In GNU Bash-2.05b (Fedora Core 1), I observe the following behaviour: > > If bash script A is invoked (via "source") with command line parameters, > and bash script A invokes (via "source") bash script B with NO > parameters specified, then the parameters specified for A ar

Re: BASH bug or expected behaviour?

Dean K. Gibson wrote: > If bash script A is invoked (via "source") with command line parameters, > and bash script A invokes (via "source") bash script B with NO > parameters specified, then the parameters specified for A are passed to > B (rather than what I would have thought would be the expe

Re: BASH Bug???

%% <[EMAIL PROTECTED]> writes: n> I have loaded BASH on a Ultra 5 running Solaris 8. The BASH binary n> was downloaded from Sunfreeware. If I load BASH as my login shell n> (i.e. passwd file change) I am unable to FTP into the system as n> that user. Edit the /etc/shells file on the So

Re: BASH Bug???

> I have loaded BASH on a Ultra 5 running Solaris 8. The BASH binary was > downloaded from Sunfreeware. If I load BASH as my login shell (i.e. > passwd file change) I am unable to FTP into the system as that user. If > I load another shell as my login shell first then call the BASH shell > from