Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024, 20:54 Greg Wooledge wrote: > On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > > After further examination, the examples with "fg $$" and "fg $!" clearly > do not bring the subshell into the foreground, as they are evaluated prior > to the subshells background

Re: possible bash bug bringing job. to foreground

I was unaware of TMOUT. Now I have a backup as well. Thanks for tolerating my inexperience. On Sat, Feb 17, 2024 at 2:54 PM, Greg Wooledge wrote: On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do >

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do > not bring the subshell into the foreground, as they are evaluated prior to > the subshells background execution. > I'm trying to bring the subshell to the

Re: possible bash bug bringing job. to foreground

After further examination, the examples with "fg $$" and "fg $!" clearly do not bring the subshell into the foreground, as they are evaluated prior to the subshells background execution. I'm trying to bring the subshell to the foreground to perform an exit, after a delay. Ultimately, it will be

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote: > Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg > %+; exit ) &  You're using %% or %+ inside a shell where there have NOT been any background jobs created yet. The sleep 15s runs in the foreground,

possible bash bug bringing job. to foreground

Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux

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

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

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

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

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

Bash Bug - Incorrect Printing of Escaped Characters

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't seem to be considered. So, for

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

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

Bash Bug

dead.bashbug Description: Binary data

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

bash bug about Chinese translation

Version : 5.1.16 OS: Fedora Problem: under Chinese (both simplified and tradition), bash buildin command 'type' has traslation mistake in its help file. Under zh_TW.utf8, 'type --help' shows type: type [-afptP] 名�Q [名�Q …] �@示指令��型的�Y��。 ��於每一�� <名�Q>，指示如果做�橹噶钏��⑷绾伪唤忉�。 �x��： -a

Re: "unset x[0], a BASH bug?"

On Thu, May 06, 2021 at 10:42:36AM +0300, Oğuz wrote: > 6 Mayıs 2021 Perşembe tarihinde Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> yazdı: > > > > But why is $# decremented after the first unset? > > Because `x[0]' existed then, and the number of x's members changed with its > removal.

Re: "unset x[0], a BASH bug?"

6 Mayıs 2021 Perşembe tarihinde Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> yazdı: > > But why is $# decremented after the first unset? > Because `x[0]' existed then, and the number of x's members changed with its removal. `${#x[@]}' doesn't give you the top index of `x', it expands to the

Re: "unset x[0], a BASH bug?"

6 Mayıs 2021 Perşembe tarihinde Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> yazdı: > Hi! > > Considering the example given in https://unix.stackexchange. > com/a/648243/320598 I think it may be a bug, or an inappropriately > documented feature. > > Basically: > % x=(1 2 3) > % echo

"unset x[0], a BASH bug?"

Hi! Considering the example given in https://unix.stackexchange.com/a/648243/320598 I think it may be a bug, or an inappropriately documented feature. Basically: % x=(1 2 3) % echo "${#x[@]}"; echo "${x[@]}" 3 1 2 3 % unset x[0] % echo "${#x[@]}"; echo "${x[@]}" 2 2 3 % unset x[0] % echo

Re: Likely Bash bug

Jay via Bug reports for the GNU Bourne Again SHell writes: > I have no idea what the "ash" the bug report refers to > is (there is an ancient shell of that name, but I cannot imagine any > distribution including that, instead of one of its bug fixed and updated > successors, like say, dash)

Re: Likely Bash bug

Thanks for your feedback. For reference, other details are as follows: In addition to bash, the distribution includes sh and ash shells/scripts. ▶—— Linux Kernel ——◀ Kernel Release: 4.19.23 Build Date: Tue Feb 19 15:07:58 GMT 2019 Build GCC: 7.3.0 OS Support:

Re: Likely Bash bug

On Wed, 17 Mar 2021 at 23:05, Greg Wooledge wrote: > On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote: > > | Operating system is BionicPup64 8.0. > > That might. More importantly is probably whatever package management > > system it uses. I have no idea what the "ash" the bug

Re: Likely Bash bug

On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote: > | Operating system is BionicPup64 8.0. > > That might. More importantly is probably whatever package management > system it uses. I have no idea what the "ash" the bug report refers to > is (there is an ancient shell of that

Re: Likely Bash bug

Date:Tue, 16 Mar 2021 22:08:17 -0500 From:Dennis Williamson Message-ID: | In any case this points to larger chunks being more efficient. This is not news, doing reads (or writes) using bigger buffers (more bytes at a time) means less system calls, and compared

Re: Likely Bash bug

Date:Tue, 16 Mar 2021 18:01:24 -0400 From:Jay via Bug reports for the GNU Bourne Again SHell Message-ID: <86f1f224-2930-ee73-5431-6e130d92f...@aim.com> First, thanks Lawrence for the translation from RTF, I am one of the people he intended to help... The RTF form

Re: Likely Bash bug

. On Tue, Mar 16, 2021, 10:22 PM Lawrence Velázquez wrote: > > On Mar 16, 2021, at 11:08 PM, Dennis Williamson < > dennistwilliam...@gmail.com> wrote: > > > > I've been playing with your optimized code changing the read to grab data > > in chunks like some of the other optimized code does -

Re: Likely Bash bug

> On Mar 16, 2021, at 11:08 PM, Dennis Williamson > wrote: > > I've been playing with your optimized code changing the read to grab data > in chunks like some of the other optimized code does - thus extending your > move from by-word to by-line reading to reading a specified larger number > of

Re: Likely Bash bug

On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez wrote: > > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne > Again SHell wrote: > > > > Hello, > > > > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple > > systems more than once either through their

Re: Likely Bash bug

> On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne Again > SHell wrote: > > Hello, > > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple > systems more than once either through their instability with libraries > or just excess stress. > > I

Likely Bash bug

Hello, I have been using/exploring Linux for ~ 2yrs; have corrupted a couple systems more than once either through their instability with libraries or just excess stress. I don't consider current case to be either of the above; see attached. The system is modern Intel

Re: A bash bug? sh_malloc missing

On 2/1/21 5:29 PM, George R Goffe wrote: Hi, I just checked out the "latest" bash from the repo at savanna.gnu.org and am having build problems. I have tried --with-gnu-malloc and it's alias and also tried building without any malloc parameters in configure without success. Enclosed below is

A bash bug? sh_malloc missing

Hi, I just checked out the "latest" bash from the repo at savanna.gnu.org and am having build problems. I have tried --with-gnu-malloc and it's alias and also tried building without any malloc parameters in configure without success. Enclosed below is what I'm seeing. I have a full build log

Re: A possible bash bug.

On 10/11/19 12:07 AM, George R Goffe via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > > I've been seeing these crashes randomly for the past month. This happens when > I try to use filename completion. Is this a bash bug? It's hard to say, since the crash is apparently

A possible bash bug.

Hi, I've been seeing these crashes randomly for the past month. This happens when I try to use filename completion. Is this a bash bug? Regards, George... This is the bash version: bash-5.0.7-3.fc31.x86_64 xpdAssertion 'pthread_mutex_init(>memfd_cache_mutex, NULL) == 0' failed at

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

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

bash bug with root account

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 .!(?(.)) the output is without error. (the output

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

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

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'

bash bug - unexpect file deleted using rm command

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_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat'

Re: $"\t': Bash bug or not?

On Sat, 18 Nov 2017, PePa wrote: On 11/15/2017 11:06 PM, Greg Wooledge wrote: On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote: tab=$'\t' echo "$tab " | xod Where can I get xod? I don't know about xod, but od is a standard utility, and hd is also commonly installed. --

Re: $"\t': Bash bug or not?

On 11/15/2017 11:06 PM, Greg Wooledge wrote: On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote: tab=$'\t' echo "$tab " | xod Where can I get xod? I tried looking here https://github.com/xodio/xod and I found a perl script that couldn't be piped into. Peter

Re: $"\t': Bash bug or not?

On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote: > $ echo "$'\t' " | xod > > Dump: standard input > > Offset:0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > > : 24 27 5c 74 27 20 0a | $'

Re: $"\t': Bash bug or not?

To put Chet's reply a different way, don't think of $'...' as a dollar expansion ( like ${} $() or $(()) ) it isn't, it is just another form of quoting (very similar to '' quoting) and is processed in the same way, at the same places, as '' quoting would be. In "'xxx'" the single quotes are just

Re: $"\t': Bash bug or not?

On 11/15/17 10:01 AM, Rick Richardson wrote: > $ echo "$'\t' " | xod > > Dump: standard input > > Offset:0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > > : 24 27 5c 74 27 20 0a | $'\t' .

$"\t': Bash bug or not?

3 4 5 6 7 8 9 a b c d e f 0123456789abcdef : 24 27 5c 74 27 20 0a | $'\t' . | A Bash bug??? $ echo $'\t'' ' | xod Dump: standard input Offset:0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef

Re: I Don't think it; 's a Bash bug in the classical sense but it is still very important for me to share with you

On 4/23/17 2:52 AM, Noneofthebusiness Ofsomehere wrote: > There is an annoying problem I struggle with that might be associated with > tab completion. I would like to share it with you. It might be a bug. I > really don't know and I'm new to Linux and programming, hence I am being > extra careful

I Don't think it; 's a Bash bug in the classical sense but it is still very important for me to share with you

There is an annoying problem I struggle with that might be associated with tab completion. I would like to share it with you. It might be a bug. I really don't know and I'm new to Linux and programming, hence I am being extra careful in naming this a bug:

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

Bash bug

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 obviously the return value is 1. B(){ return_value="$(bash -c "exit 1")"

Re: Possible bash bug?

> Am 22.06.2016 um 11:34 schrieb John Lawlor : > > Hi, > > I came across some unusual behaviour in bash using the ‘-c’ parameter. > > If I do the following: > > bash -c "ping 127.0.0.1 > $HOME/console.log" & > > This starts two processes bash and ping: > > john

Re: Possible bash bug?

On Wed, Jun 22, 2016 at 10:34:59AM +0100, John Lawlor wrote: > If I do the following: > > bash -c "ping 127.0.0.1 > $HOME/console.log" & > Now if I kill bash: > > Bash is killed but not the child ping process. I was expecting that to be > killed also. Not a bug. If you want a signal (e.g.

Possible bash bug?

Hi, I came across some unusual behaviour in bash using the '-c' parameter. If I do the following: bash -c "ping 127.0.0.1 > $HOME/console.log" & This starts two processes bash and ping: john 18038 17951 0 09:26 pts/14 00:00:00 bash -c ping 127.0.0.1 > /home/john/console.log john

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

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

Bash bug in variable assignment/echo/grep -q

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_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'

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 rich...@marsden.nu wrote: steps to produce hide cursor setterm -cursor off call the bash built-in read command as

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 + c is

bash bug with read -s command

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 + c is trapped successfully and the cursor is un-hidden setterm

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 fix is

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

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

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 should be

Bash bug - in read -e -r var

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 should be in the same format that the read is expecting, so if

Re: possible bash bug - 'history'

On 2013-08-09 16:10, Chet Ramey wrote: So is there enough of a need to make 0 do something different? Or does $BASH_COMMAND suffice? (I suspect the answer to that question is no, because it deals with commands rather than input lines.) I agree, for this case I don't think $BASH_COMMAND

Re: possible bash bug - 'history'

On 7/19/13 11:23 AM, Mike Fied wrote: Dear GNU developer/code maintainer, Please take a second to take a look at this problem - this might or might not be a bug, or rather a feature is not implemented in BASH: I am trying to get the current or last command line printed as the result of

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 del sp nl 003

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 output is: 000 del nl

Re: Severe Bash Bug with Arrays

This mail has gone slightly off-topic. Hit mark as read if you don't care for that sort of thing. On 27 Apr 2012, at 21:02, Linda Walsh wrote: Greg Wooledge wrote: NEVER use eval plus a brace expansion to generate a list. That's just freakin' evil. And unsafe: But I _like_ evil

Re: Severe Bash Bug with Arrays

Maarten Billemont wrote: This mail has gone slightly off-topic. Hit mark as read if you don't care for that sort of thing. I don't care if you like evil in your sexual play or in your vendettas. When you write code, evil is nothing worth liking. In programming, evil is defined as

Fwd: Bash bug interpolating delete characters

---BeginMessage--- 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 del sp nl 003 000 sp del nl 003 however with bash

Re: Fwd: Bash bug interpolating delete characters

Yours, Rüdiger. a=x del=$(echo -e \\x7f) echo $del${a#x} | od -ta echo $del ${a#x} | od -ta echo $del${a#x} | od -ta Yup, confirmed that it breaks here, and only when the # parameter expansion is included. imadev:~$ del=$'\x7f' a=x b= imadev:~$ echo $del$b | od -ta 000 sp del

Re: Fwd: Bash bug interpolating delete characters

Am 03.05.2012 15:01, schrieb Greg Wooledge: Yours, Rüdiger. a=x del=$(echo -e \\x7f) echo $del${a#x} | od -ta echo $del ${a#x} | od -ta echo $del${a#x} | od -ta Yup, confirmed that it breaks here, and only when the # parameter expansion is included. imadev:~$ del=$'\x7f' a=x b=

Re: Fwd: Bash bug interpolating delete characters

Am 03.05.2012 19:41, schrieb John Kearney: Am 03.05.2012 15:01, schrieb Greg Wooledge: Yours, Rüdiger. a=x del=$(echo -e \\x7f) echo $del${a#x} | od -ta echo $del ${a#x} | od -ta echo $del${a#x} | od -ta Yup, confirmed that it breaks here, and only when the # parameter expansion is

Re: Severe Bash Bug with Arrays

On Thu, Apr 26, 2012 at 08:47:39PM -0700, Linda Walsh wrote: Obviously, they were not complete beginners to bash -- to be reading arrays in from vars holding multi-line text? I would assume they'd have the intelligence to know when to use * or @ and I wouldn't have to talk down to them

Re: Severe Bash Bug with Arrays

Greg Wooledge wrote: NEVER use eval plus a brace expansion to generate a list. That's just freakin' evil. And unsafe: === But I _like_ evil sometimes! :- imadev:~$ a=(lib tmp bin share '`date`') imadev:~$ (export IFS=,;eval echo /usr/{${a[*]}}) /usr/lib /usr/tmp /usr/bin /usr/share

Re: reply style (OT) (was Re: Severe Bash Bug w/Arrays)

Mike Frysinger wrote: Anything else you wanna tell me NEVER/ALWAYS to do? try ALWAYS being polite. but i guess that'll NEVER happen. oh well, thankfully kmail can auto-mute based on sender. -mike «Always good to prejudge everything someone says based on how they interact with

Re: Severe Bash Bug with Arrays

On 26 Apr 2012, at 01:18, Linda Walsh wrote: Ishtar: echo ${b[*]} Please note that expanding array elements using [*] is usually NOT what anyone wants. Be careful about recommending it to anyone. ${b[*]} # This throws away any usefulness of the array by merging all the array elements into

Re: Severe Bash Bug with Arrays

On Thu, Apr 26, 2012 at 05:54:27PM +0200, Maarten Billemont wrote: On 26 Apr 2012, at 01:18, Linda Walsh wrote: Ishtar: echo ${b[*]} You should always recommend the ${b[@]} variant. ${b[*]} is rarely useful in the event that your intent is to merge the array into a single string, eg.

Re: Severe Bash Bug with Arrays

On Thu, Apr 26, 2012 at 2:16 PM, Greg Wooledge wool...@eeg.ccf.org wrote: If the goal is to see the contents of an array, I'd use one of these, depending on how much detail I need: printf '%s ' ${array[@]}; echo declare -p array Or i'd use the args function Greg has shown before: args()

Re: Severe Bash Bug with Arrays

Maarten Billemont wrote: On 26 Apr 2012, at 01:18, Linda Walsh wrote: Ishtar: echo ${b[*]} Please note that expanding array elements using [*] is usually NOT what anyone wants. --- It was exactly what I wanted for my example to work. Please don't suggest non-working solutions to the

Re: Severe Bash Bug with Arrays

On Thursday 26 April 2012 23:47:39 Linda Walsh wrote: Anything else you wanna tell me NEVER/ALWAYS to do? try ALWAYS being polite. but i guess that'll NEVER happen. oh well, thankfully kmail can auto-mute based on sender. -mike signature.asc Description: This is a digitally signed message

Re: Severe Bash Bug with Arrays

On 4/25/12 1:23 AM, Clark Wang wrote: Bash Version: 4.2 Patch Level: 0 Release Status: release Description: Cannot redirect into an array from multiline variable Does not work: echo $mydata | while read line; do myarray+=( $line ); done Here the whole *while* statement runs in

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 08:40:11AM -0400, Chet Ramey wrote: Since you're using bash-4.2, you can experiment with the `lastpipe' shopt option. If that's enabled, bash runs the last element of a pipeline in the parent shell context without creating a subshell. I actually started writing a

Re: Severe Bash Bug with Arrays

On 4/25/12 10:55 AM, Greg Wooledge wrote: On Wed, Apr 25, 2012 at 08:40:11AM -0400, Chet Ramey wrote: Since you're using bash-4.2, you can experiment with the `lastpipe' shopt option. If that's enabled, bash runs the last element of a pipeline in the parent shell context without creating a

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote: z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION' 4.2.24(9)-release z4.local(1)$ ../bash-4.2-patched/bash ./x3 foo z4.local(1)$ ./x3 foo I grabbed patches 21-24 and applied them. No change.

Re: Severe Bash Bug with Arrays

On 4/25/12 11:27 AM, Greg Wooledge wrote: On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote: z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION' 4.2.24(9)-release z4.local(1)$ ../bash-4.2-patched/bash ./x3 foo z4.local(1)$ ./x3 foo I grabbed patches 21-24 and applied

Re: Severe Bash Bug with Arrays

On 04/25/2012 06:15 PM, Chet Ramey wrote: On 4/25/12 11:27 AM, Greg Wooledge wrote: On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote: z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION' 4.2.24(9)-release z4.local(1)$ ../bash-4.2-patched/bash ./x3 foo z4.local(1)$ ./x3 foo

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 06:26:18PM +0200, Roman Rakus wrote: On 04/25/2012 06:15 PM, Chet Ramey wrote: OK. I get the same working behavior on Mac OS X, Solaris 8/10, RHEL 5, BSD/OS (old), and Fedora 15. I'm not sure what to tell you. On Fedora 16 it works as expected. $ rpm -q bash

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 12:55:06PM -0400, Greg Wooledge wrote: It also fails on OpenBSD 5.0 using bash 4.2.10 from ports. And it also fails on OpenBSD 5.0 using bash 4.2.24 straight from the original sources. cyclops:/var/tmp/bash/bash-4.2$ ./bash -c 'echo $BASH_VERSION' 4.2.24(1)-release

Re: Severe Bash Bug with Arrays

On 4/25/12 1:10 PM, Greg Wooledge wrote: On Wed, Apr 25, 2012 at 12:55:06PM -0400, Greg Wooledge wrote: It also fails on OpenBSD 5.0 using bash 4.2.10 from ports. And it also fails on OpenBSD 5.0 using bash 4.2.24 straight from the original sources. OK. Maybe someone with OpenBSD can debug

Re: Severe Bash Bug with Arrays

Please note that if I use a different command in the while loop it works. So instead of echo $mydata | while read -r line; do myarray+=( $line ); done if I say: echo $mydata | while read -r line; do echo $line ; done Then it works. To pipe output into a while statement works, normally, however

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 10:36:53AM -0700, Ted Okuzumi wrote: Please note that if I use a different command in the while loop it works. So instead of echo $mydata | while read -r line; do myarray+=( $line ); done if I say: echo $mydata | while read -r line; do echo $line ; done You do not

Re: Severe Bash Bug with Arrays

On Wed, Apr 25, 2012 at 1:36 PM, Ted Okuzumi tedokuz...@gmail.com wrote: Please note that if I use a different command in the while loop it works. So instead of echo $mydata | while read -r line; do myarray+=( $line ); done if I say: echo $mydata | while read -r line; do echo $line ; done

  1   2   >