Re: possible bash bug bringing job. to foreground

[alex xmb sw ratchev]

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 execution.
> > I'm trying to bring the subshell to the foreground to perform an exit,
> after a delay.
> > Ultimately, it will be used as part of a terminal emulator inactivity
> timeout.
>
> Bash already has a TMOUT variable which will cause an interactive shell
> to exit after a specified length of inactivity.  Is that sufficient?
> If not, how does your desired solution need to differ from TMOUT?
>

i never heard of TMOUT before , too

>

Re: possible bash bug bringing job. to foreground

[John Larew]

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 
> 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 used as part of a terminal emulator inactivity timeout.

Bash already has a TMOUT variable which will cause an interactive shell
to exit after a specified length of inactivity.  Is that sufficient?
If not, how does your desired solution need to differ from TMOUT?
  

Re: possible bash bug bringing job. to foreground

[Greg Wooledge]

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 foreground to perform an exit, after 
> a delay.
> Ultimately, it will be used as part of a terminal emulator inactivity timeout.

Bash already has a TMOUT variable which will cause an interactive shell
to exit after a specified length of inactivity.  Is that sufficient?
If not, how does your desired solution need to differ from TMOUT?

Re: possible bash bug bringing job. to foreground

[John Larew]

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 used as part of a terminal emulator inactivity timeout.
I suspected there are advantages to exiting the emulator vs. killing the 
process.
Clearly, I misunderstood. Thanks again.

Re: possible bash bug bringing job. to foreground

[Greg Wooledge]

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,
because it doesn't have a & after it.

> Fix: (sleep 15s; set -m; kill $PPID) &     Not a preferred solution; I prefer 
> a smaller hammer.

It's not clear to me what you're trying to do in the first examples.
Did you think that the subshell would somehow "take over" the terminal
and become the interactive shell, after the 15 second delay?  And what
would that achieve, if it worked?

In the "Fix" example, you're killing the main shell's parent, which
is most likely a terminal emulator.  Did you want to kill the main
shell instead of the terminal?  If so, you can get its PID with
the $$ variable.  Even inside a subshell, $$ always refers to the main
shell's PID.  If you want the subshell's PID, use BASHPID instead.

What exactly is it about the "Fix" example that you don't prefer?
What goal are you trying to achieve?

possible bash bug bringing job. to foreground

[John Larew]

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 
HP-ProBook-6450b-500GB 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/LinuxMachine Type: 
x86_64-pc-linux-gnu
Bash Version: 5.1Patch Level: 16Release Status: release
Description: This is an attempted portion of a larger script I am writing. All 
these attempts appear valid; none works.
 BTW, also fails on termux 0.118.0/bash v5.22.6 (HOSTTYPE=aarch64, 
MACHTYPE=aarch64-unknown-linux-android)
Repeat-By:  1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg 
%+; exit ) & 
Fix: (sleep 15s; set -m; kill $PPID) &     Not a preferred solution; I prefer a 
smaller hammer.

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

   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 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 branch here:
   [2]https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b00
   29

References

   1. mailto:sethsa...@gmail.com
   2. https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b0029

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Grisha Levit]

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 branch here:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b0029

>

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

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,
> >
> > 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
> > example, in a bash script with character */001* the AST representation
> > will contain */001/001*, however, when it's printed via the pretty print
> > feature, this isn't un-escaped.
>
> Thanks for the report. This affects word lists, the word in a case
> command, and shell function names. The fix is to dequote those words when
> in pretty-printing mode. You could do that for the name in a select
> command, too, but that's an invalid identifier to begin with.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Chet Ramey]

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't seem to be considered. So, for
example, in a bash script with character */001* the AST representation
will contain */001/001*, however, when it's printed via the pretty print
feature, this isn't un-escaped.


Thanks for the report. This affects word lists, the word in a case
command, and shell function names. The fix is to dequote those words when
in pretty-printing mode. You could do that for the name in a select
command, too, but that's an invalid identifier to begin with.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Eric Pruitt]

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/bash.git
Cloning into 'bash'...
remote: Counting objects: 41221, done.
remote: Compressing objects: 100% (5024/5024), done.
remote: Total 41221 (delta 36225), reused 41045 (delta 36106)
Receiving objects: 100% (41221/41221), 259.98 MiB | 15.65 MiB/s, done.
Resolving deltas: 100% (36225/36225), done.
$ cd bash/doc/
doc$ fgrep -r pretty
texinfo.tex:% above.  But it's pretty close.
texinfo.tex:  % and a tt hyphen is pretty tiny.  @code also disables ?` !`.
doc$

Eric

Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

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
example, in a bash script with character */001* the AST representation
will contain */001/001*, however, when it's printed via the pretty print
feature, this isn't un-escaped.

Steps to reproduce:

Download the following version of bash (this is the latest version of
bash-5.2 as of sending this email):
https://git.savannah.gnu.org/cgit/bash.git/commit/?id=4b0f8ba28449c60d6b3436d0c98b14e016b232c2

After extracting the tar file run the *configure* script and *make clean
all* as usual to prepare the bash executable.

Copy the attached *test.sh* into the bash directory.

Run the following command: ./bash --pretty-print test.sh > test2.sh
Then run: ./bash --pretty-print test2.sh > test3.sh

Observe the exponential growth of the escape character */001* in the bash
files.

I believe the following files in the *tests* directory in the bash source
directory may also be used to reproduce this issue:

case2.sub,
nquote3.sub,
dollar-star6.sub,
nquote5.sub,
exp6.sub,
exp7.sub,
quote4.sub,
cond-regexp1.sub,
iquote1.sub,
exp1.sub,
rhs-exp1.sub,
cond-regexp3.sub,
glob8.sub,
posixexp6.sub,
new-exp6.sub,
dollar-at-star10.sub,
dollar-at-star4.sub

Additional Information:

My computer: 2020 13-inch Macbook Pro on MacOS 14.1.2

However, I should note that I was able to reproduce this issue on Linux.

Thanks all and Merry Christmas,
Seth
var1=$'\001'

Re: Bash Bug

[alex xmb ratchev]

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

sorry didnt bash lists the mail

>
> On Tue, Jun 27, 2023, 01:16 alex xmb ratchev  wrote:
>>
>>> 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

[alex xmb ratchev]

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

[Kaif Khan]

dead.bashbug
Description: Binary data

Re: bash bug about Chinese translation

[Chet Ramey]

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 forwarded this message to coordina...@translationproject.org.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

bash bug about Chinese translation

[C. Cicada]

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�@示所有包含名�Q�� <名�Q> 的可�绦��n案的位置；
   包括�e名、�冉ê秃��怠��H��「-p」�x���]有使用�r
 -f抑制 shell 函�挡樵�
 -P�槊��� <名�Q> �@醒 PATH 路�剿��ぃ�即使它是�e名、
   �冉�或函�担��K且回���⒈��绦械拇诺�上�n案的名�Q。
 -p回���⒈��绦械拇诺�上�n案的名�Q，或者��「type -t <名�Q>」
   不回�鳌�file」�r，不回�魅魏沃怠�
 -t回�飨铝性~中的任何一��「alias」、「keyword」、
   「function」、「builtin」、「file」或者「」，如果 <名�Q> 是相��的
   一���e名、shell 保留字、shell 函�怠�shell �冉ㄎ锛�、
   磁碟�n案或�]有找到。

   ���担�
 <名�Q>�⒁�解析的指令。

   退出���B：
   如果所有的 <名�Q> 指令都找到�t回�鞒晒Γ蝗魏握也坏��t失�　�

The highlighted two characters are not correct. It should be �M行. (Here the 
highlighting maybe cannot be seen if unfortunate things happen. Please reply to 
me if it really happens) This mistake happens because two words pronounce 
similar, which is somehow like spelling mistakes in English.

Similar problem happens in simplified Chinese. Under zh_CN.utf8, 'type --help' 
shows

type: type [-afptP] 名称 [名称 ...]
   显示命令类型的信息。

   对于每一个 NAME 名称，指示如果作为命令它将如何被解释。

   选项：
 -a显示所有包含名称为 NAME 的可执行文件的位置；
   包括别名、内建和函数。仅当 `-p' 选项没有使用时
 -f抑制 shell 函数查询
 -P为每个 NAME 名称惊醒 PATH 路径搜索，即使它是别名、
   内建或函数，并且返回将被执行的磁盘上文件的名称。
 -p返回将被执行的磁盘上文件的名称，或者当 `type -t NAME'
   不返回 `file' 时，不返回任何值。
 -t返回下列词中的任何一个 `alias'、`keyword'、
   `function'、`builtin'、`file' 或者 `'，相应地如果 NAME 是
   一个别名、shell 保留字、shell 函数、shell 内建、
   磁盘文件或没有找到。

   参数：
 NAME  将要解析的命令。

   退出状态：
   如果所有的 NAME 命令都找到则返回成功；任何一个找不到则失败。

The highlighted characters should be 进行.

Noting that Not only zh_CN.utf8 and zh_TW.utf8 may have this problem. It may 
probably exist in every Chinese format. Besides, I also checked bash 5.0.17 
under Ubuntu 20.04 and same thing happened, so I guess it is a translation 
mistake for a rather long time.

 Thanks

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

[Greg Wooledge]

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. `${#x[@]}' doesn't give you the top index of `x', it expands to
> the number of elements in `x'.

A helpful tip might be to use declare -p to show the array, instead of
simply echoing the values.

unicorn:~$ x=(1 2 3)
unicorn:~$ declare -p x
declare -a x=([0]="1" [1]="2" [2]="3")
unicorn:~$ unset 'x[0]'
unicorn:~$ declare -p x
declare -a x=([1]="2" [2]="3")

The other thing you need to watch out for is pathname expansion.  x[0]
is a valid glob, and if you have a file named x0 in the current directory,
an unquoted x[0] will be expanded to x0, and then you'll be running
"unset x0" instead of what you intended.

Use quotes the way I showed in my example to avoid that issue.

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

[Oğuz]

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 number of elements in `x'. I suspect you don't know that bash arrays
can be sparse. Well, they can be.

$ x=([42]=foo [69]=bar)
$ echo "${#x[@]}"
2
$ echo "${!x[@]}"
42 69
$ echo "${x[@]}"
foo bar


-- 
Oğuz

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

[Oğuz]

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 "${#x[@]}"; echo "${x[@]}"
> 3
> 1 2 3
> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3
> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3


`unset x[0]' doesn't change indexes of other elements in `x'.

$ x=(1 2 3)
$ declare -p x
declare -a x=([0]="1" [1]="2" [2]="3")
$ unset x[0]
$ declare -p x
declare -a x=([1]="2" [2]="3")

And there is nothing in the documentation that suggests otherwise.


> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3
>
>

-- 
Oğuz

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

[Ulrich Windl]

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 "${#x[@]}"; echo "${x[@]}"
2
2 3
% unset x[0]
% echo "${#x[@]}"; echo "${x[@]}"
2
2 3

Re: Likely Bash bug

[Dale R. Worley]

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)

Well, I read years ago of a lightweight shall named "ash" that was
popular within initrd's.  And the report speaks of "the 'init' script in
initrd.gz".  So perhaps that initrd uses some version of ash.

Don't know if that's any help,

Dale

Re: Likely Bash bug

[Jay via Bug reports for the GNU Bourne Again SHell]

   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: GNU/Linux
   Architecture: x86_64
   SMP Enabled: Yes
   Kernel Command Line:
   psave=/Bionicpup64save-jay pmedia=ataflash pfix=fsck  #pmedia=atahd
   ▶—— Distro Specifications ——◀
   Distro: bionicpup64 8.0
   Window Manager: JWM v2.3.7
   Desktop Start: xwin jwm
   Development:
Bash: 4.4.19
Geany: 1.33
Gtkdialog: 0.8.4
Perl: 5.26.1
Python: 2.7.15rc1
Yad: 0.40.0 (GTK+ 2.24.32)
--
busybox: 1.29.3
dhcpcd: 6.6.2
Devx GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Glibc: 2.27
OpenSSL: 1.1.0g  2 Nov 2017, built on: reproducible build, date
   unspecified
wpa_supplicant: 2.6
   ▶—— /etc/DISTRO_SPECS ——◀
   One or more words that identify this distribution:
• DISTRO_NAME='bionicpup64'
   Version number of this distribution:
• DISTRO_VERSION=8.0
   The distro whose binary packages were used to build this distribution:
• DISTRO_BINARY_COMPAT='ubuntu'
   Prefix for some filenames: exs: bionicpup64save.2fs,
   bionicpup64-7.9.8.sfs
• DISTRO_FILE_PREFIX='bionicpup64'
   The version of the distro whose binary packages were used to build this
   distro:
• DISTRO_COMPAT_VERSION='bionic'
   Read by /usr/bin/xwin to bypass Xorg Wizard at first boot:
• DISTRO_XORG_AUTO='yes'
• DISTRO_KERNEL_PET='Huge_Kernel'
• DISTRO_DB_SUBNAME='bionic64'
• WOOF_VERSION=8
• DISTRO_TARGETARCH='x86_64'
• BUILD_FROM_WOOF='testing;c3552eef;2019-02-25 04:50:55 +0800'
   Puppy default filenames...
   Note, the 'SFS' files below are what the 'init' script in initrd.gz
   searches for,
   For the partition, path and actual files loaded, see PUPSFS and ZDRV in
   /etc/rc.d/PUPSTATE
• DISTRO_PUPPYSFS='puppy_bionicpup64_8.0.sfs'
• DISTRO_ZDRVSFS='zdrv_bionicpup64_8.0.sfs'
• DISTRO_FDRVSFS='fdrv_bionicpup64_8.0.sfs'
• DISTRO_ADRVSFS='adrv_bionicpup64_8.0.sfs'
• DISTRO_YDRVSFS='ydrv_bionicpup64_8.0.sfs'
• DISTRO_PUPPYDATE='Feb 2019'
   Multiarch distros, such as Ubuntu, will have this. ex:
   /usr/lib/i386-linux-gnu, so DISTRO_ARCHDIR=i386-linux-gnu
• DISTRO_ARCHDIR='x86_64-linux-gnu'
   ▶—— /etc/os-release ——◀
   NAME=Puppy
   VERSION="8.0"
   ID=puppy_bionicpup64
   VERSION_ID=8.0
   PRETTY_NAME="bionicpup64 8.0"
   ANSI_COLOR="0;34"
   CPE_NAME="cpe:/o:puppy:puppy_linux:8.0"
   HOME_URL=[1]"http://puppylinux.com/;
   SUPPORT_URL=[2]"http://www.murga-linux.com/puppy/index.php;
   BUG_REPORT_URL=[3]"https://github.com/puppylinux-woof-CE/woof-CE;

   Best Regards.

   On 3/16/2021 11:59 PM, Robert Elz wrote:

Date:Tue, 16 Mar 2021 18:01:24 -0400
From:Jay via Bug reports for the GNU Bourne Again SHell [4]
Message-ID:  [5]<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 I was going to
simply ignore.

  |The system is modern Intel computer, 2018 to 2019 configured in BIOS
  |mode.

That should make no difference.

  | 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 name, but I cannot imagine any
distribution including that, instead of one of its bug fixed and updated
successors, like say, dash) but it seems to me as if the problem here
relates to whatever package manager was used, that doesn't keep track of
what files various packages touch, and allows one package to overwrite
another's files.   That is, not a bash problem at all.   The OS might
also have issues, if doing things to files can cause it to crash, but it
is more likely, that ash, whatever it is, did something which caused a
problem, when some of its files were destroyed by the package manager.

Finally, it is generally not a good idea to do anything as "root" (or
using sudo to the same effect) if you aren't 100% confident in what you
are doing.

kre

References

   1. http://puppylinux.com/
   2. http://www.murga-linux.com/puppy/index.php
   3. https://github.com/puppylinux-woof-CE/woof-CE
   4. mailto:bug-bash@gnu.org
   5. mailto:86f1f224-2930-ee73-5431-6e130d92f...@aim.com

Re: Likely Bash bug

[David]

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

> "ash" is often secret code for "busybox sh".

> In this specific case, I'm not sure *what* it is.  I googled a few things
> and came up with this page:

> http://wikka.puppylinux.com/Ash

That page was last edited in 2011.

The package list for BionicPup64 8.0 (or other versions) can be found here:
https://distrowatch.com/table.php?distribution=puppy=true=8.0#pkglist

Looks like the provided shells are bash 4.4.18 and busybox 1.29.3

But I wonder if this bug is reproducible even by the reporter.

Re: Likely Bash bug

[Greg Wooledge]

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 name, but I cannot imagine any
> distribution including that, instead of one of its bug fixed and updated
> successors, like say, dash)

"ash" is often secret code for "busybox sh".

In this specific case, I'm not sure *what* it is.  I googled a few things
and came up with this page:

http://wikka.puppylinux.com/Ash

It says:

   Ash is a shell or command line interpreter. It acts as a cut down
   version of Bash with less commands. Puppy uses the Ash shell up to
   v 1.0.2

I'm not sure whether that's version 1.0.2 of this "ash" (whatever it
is), or of Puppy Linux.

> That is, not a bash problem at all.

Quite.

"Hi, I broke my OS, and I don't know how to fix it, and I don't know
how to contact my OS vendor's support, so I'll just file a bug against
a random shell instead!  Even though it's not the shell I'm using!"

Re: Likely Bash bug

[Robert Elz]

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 to almost anything
else that happens, system calls are expensive - doing less will make things
run faster.

Unfortunately, it can also alter the semantics of what is happening - whether
it does or not entirely depends upon the application.

Lastly, if you really care about any of this - that is, if it really matters
to something more than your ego - then you shouldn't be writing in shell at
all, but using a compiled language.   Lots of things in shell involve running
other programs, and running another program usually involves large numbers
of system calls (including fork() and exec() - two of the most costly that
exist).

Write shell scripts to do things where all the time is either spent waiting
for something to happen (like the user to type the next command) or in
some other program that the shell runs (like a compiler, or document processor)
and no-one cares just how efficient the shell might be in making all of
that happen, as in the overall scheme of things it makes no difference (kind
of like worrying how quickly you can drive down your driveway to get in or
out of your house when the real issue is how long it takes you to get
to/from work).

kre

Re: Likely Bash bug

[Robert Elz]

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 I was going to
simply ignore.

  |The system is modern Intel computer, 2018 to 2019 configured in BIOS
  |mode.

That should make no difference.

  | 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 name, but I cannot imagine any
distribution including that, instead of one of its bug fixed and updated
successors, like say, dash) but it seems to me as if the problem here
relates to whatever package manager was used, that doesn't keep track of
what files various packages touch, and allows one package to overwrite
another's files.   That is, not a bash problem at all.   The OS might
also have issues, if doing things to files can cause it to crash, but it
is more likely, that ash, whatever it is, did something which caused a
problem, when some of its files were destroyed by the package manager.

Finally, it is generally not a good idea to do anything as "root" (or
using sudo to the same effect) if you aren't 100% confident in what you
are doing.

kre

Re: Likely Bash bug

[Dennis Williamson]

.

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 - thus extending
> your
> > move from by-word to by-line reading to reading a specified larger number
> > of characters.
> >
> > IFS= read -r -N 4096 var
> >
> > And appending the result of a regular read to end at a newline. This
> seemed
> > to cut about 20% off the time. But I get different counts than your code.
> > I've tried using read without specifying a variable and using the
> resulting
> > $REPLY to preserve whitespace but the counts still didn't match.
> >
> > In any case this points to larger chunks being more efficient.
>
> Wrong thread?
>
> vq


Oops

Re: Likely Bash bug

[Lawrence Velázquez]

> 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 characters.
> 
> IFS= read -r -N 4096 var
> 
> And appending the result of a regular read to end at a newline. This seemed
> to cut about 20% off the time. But I get different counts than your code.
> I've tried using read without specifying a variable and using the resulting
> $REPLY to preserve whitespace but the counts still didn't match.
> 
> In any case this points to larger chunks being more efficient.

Wrong thread?

vq

Re: Likely Bash bug

[Dennis Williamson]

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 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 computer, 2018 to 2019 configured in BIOS
> >   mode. Operating system is BionicPup64 8.0.
> >
> >   Best Regards.
> > 
>
> Reproduced below for anyone who doesn't feel like reading a bug
> report out of an RTF document.
>
> vq
>
>
>
> From: root
> To: bug-bash@gnu.org,b...@packages.debian.org
> Subject: [ash--bash interference (for reference)]
>
> 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-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wno-parentheses -Wno-format-security
> uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT
> 2019 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> [Original ash executable/script reduced to 4 bytes after download
> of "Clonezilla"
> through Puppy Package Manager. Reboot of system hung at
> 'switching-layers'.]
>
> Repeat-By:
> [Believed occurred after an ash co-dependency download as part of
> install.]
>
> Fix:
> [Noted xwin errors relating to ash on shutdown; had backup
> savefile. Compared /bin and saw the difference. Replaced ash from backup
> file to working folder.]
>


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 characters.

IFS= read -r -N 4096 var

And appending the result of a regular read to end at a newline. This seemed
to cut about 20% off the time. But I get different counts than your code.
I've tried using read without specifying a variable and using the resulting
$REPLY to preserve whitespace but the counts still didn't match.

In any case this points to larger chunks being more efficient.

>

Re: Likely Bash bug

[Lawrence Velázquez]

> 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 don't consider current case to be either of the above; see attached.
> 
>   The system is modern Intel computer, 2018 to 2019 configured in BIOS
>   mode. Operating system is BionicPup64 8.0.
> 
>   Best Regards.
> 

Reproduced below for anyone who doesn't feel like reading a bug
report out of an RTF document.

vq



From: root
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: [ash--bash interference (for reference)]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT 2019 
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 19
Release Status: release

Description:
[Original ash executable/script reduced to 4 bytes after download of 
"Clonezilla" 
through Puppy Package Manager. Reboot of system hung at 'switching-layers'.]

Repeat-By:
[Believed occurred after an ash co-dependency download as part of 
install.]

Fix:
[Noted xwin errors relating to ash on shutdown; had backup savefile. 
Compared /bin and saw the difference. Replaced ash from backup file to working 
folder.]

Likely Bash bug

[Jay via Bug reports for the GNU Bourne Again SHell]

   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 computer, 2018 to 2019 configured in BIOS
   mode. Operating system is BionicPup64 8.0.

   Best Regards.


Bash-issue.rtf
Description: MS-Word document

Re: A bash bug? sh_malloc missing

[Chet Ramey]

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 what I'm 
seeing. I have a full build log available if needed.


This looks like you got part of the build compiled with BASH_MALLOC and
part without.

If you compile with the bash malloc enabled, you'll get references to
bash_malloc, but then you need to link with the bash malloc library in
${BUILD_DIR}/lib/malloc.

I'm surprised that you somehow got sh_malloc references in gen-helpfiles,
since that file explicitly undefines all of the names that would get you
using the bash malloc.

My advice is to run `make distclean' and start from scratch with the 
default build options, then go from there. Your system can't be *that*

much of an oddball.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

A bash bug? sh_malloc missing

[George R Goffe]

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 available if needed.

Regards and THANKS for your help,

George...

gcc  -DHAVE_CONFIG_H -DSHELL  -I. -I..  -I.. -I../include -I../lib -I.    -g 
-O2 -Wno-parentheses -Wno-format-security  -rdynamic -g -O2 -Wno-parentheses 
-Wno-format-security -rdynamic -g -O2 -Wno-parentheses -Wno-format-security  -o 
gen-helpfiles gen-helpfiles.o tmpbuiltins.o -ldl
/export/home/lsd/Linux/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
 
/export/home/lsd/Linux/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
 DWARF error: can't find .debug_ranges section.
gen-helpfiles.o: in function `write_helpfiles':
gen-helpfiles.c:(.text+0xdc): undefined reference to `sh_malloc'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:185: gen-helpfiles] Error 1
make[1]: Leaving directory '/export/home/tools/bash/bash/builtins'
make: *** [Makefile:737: builtins/libbuiltins.a] Error 1

Re: A possible bash bug.

[Chet Ramey]

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 from systemd (?).

> xpdAssertion 'pthread_mutex_init(>memfd_cache_mutex, NULL) == 0' failed at 
> src/libsystemd/sd-bus/sd-bus.c:257, function sd_bus_new(). Aborting.
> Warning: Program '/bin/bash' crashed.
> 


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

A possible bash bug.

[George R Goffe via Bug reports for the GNU Bourne Again SHell]

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 
src/libsystemd/sd-bus/sd-bus.c:257, function sd_bus_new(). Aborting.
Warning: Program '/bin/bash' crashed.

Re: bash bug with root account

[Greg Wooledge]

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/profile and ~root/.profile (or other login-shell-only dot files).

> > If "su" (without the -l),  is given instead, then "!" is taken to be
> This account does not.

"su" without "-" or "-l" gives a non-login shell, so this instance of
bash is only reading ~root/.bashrc (and possibly some vendor-specific
files in /etc, possibly /etc/bash.bashrc or /etc/bashrc, depending on
the vendor's compile-time options).

Understanding the difference between a login shell and a non-login shell
is the primary issue here.  If you actually want to track down where
the extglob setting is coming from (or not coming from), I'd start with
~root/.profile and ~root/.bashrc as the most likely places to look.

Enabling extglob *should* be done in .bashrc (if it's going to be done
at all), and .bashrc *should* be sourced from .profile or .bash_profile
in order to ensure that login shells and non-login shells both have the
same basic options enabled.

My first guess is your .profile isn't sourcing your .bashrc the way it
should.  But there are myriad other ways this could have been
misconfigured, and the only way to be sure will be to dig through all
of the dot files.

Re: bash bug with root account

[Chet Ramey]

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 .!(?(.))
> 
> the output is without error. (the output lists all dot items with the
> exception of the annoying literals "." and "..")

This account has the `extglob' shell option enabled.

> 
> If "su" (without the -l),  is given instead, then "!" is taken to be
> something else as though I am attempting to fire up a bash history command
> (eg: "!100" to run the 100th command from bash's history list)
> 
> The error with ls -ld .!(?(.)) after doing "su"
> "bash: !: event not found"

This account does not.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

bash bug with root account

[westlake]

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 lists all dot items with the 
exception of the annoying literals "." and "..")


If "su" (without the -l),  is given instead, then "!" is taken to 
be something else as though I am attempting to fire up a bash history 
command (eg: "!100" to run the 100th command from bash's history list)


The error with ls -ld .!(?(.)) after doing "su"
"bash: !: event not found"

I could run this command in any directory without any issue, the error 
only occurs when entering the root account in bash with "su" from 
a normal user account.


I'm not sure if this is entirely the fault of bash, but "ps" shows that 
the shell being used after typing "su" is bash.

Re: bash bug - unexpect file deleted using rm command

[Andreas Kusalananda Kähäri]

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 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' -DPACKAGE='bash' 
> > -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE 
> > -DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> > uname output: Linux minigeek.srve.com 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue 
> > Jan 15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> > Machine Type: x86_64-redhat-linux-gnu
> > 
> > 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 file, named ._.DS_Store was also erased - but 
> > without warning, and I did not ask for this.  
> > Therein lies the bug.
> > I recreated two text files with different contents having those same 
> > names, and repeated the steps - same problem - both files got erased with 
> > the one rm command for just one of them.
> > 
> > Repeat-By:
> > Create those 2 files. Delete just one.
> > 
> > Fix:
> > probably some shell filename matching code has an error?
> > 
> > 
> 
> What was your actual command when deleting the file(s)?  If no filename
> globbing pattern was used, then I think the shell can be ruled out as
> the culprit.  If a globbing pattern was used, e.g. .*DS_Store .DS_Store

Sorry, that last line got mangled by vim.  That should read:

If a globbing pattern was used, then there may be an issue with the
pattern rather than with the shell.

> 
> $ touch .DS_Store ._.DS_Store
> $ ls -la
> total 8
> drwx--  2 kkwheel  512 May 28 16:41 .
> drwxrwxrwt  7 root  wheel  512 May 28 16:41 ..
> -rw-r--r--  1 kkwheel0 May 28 16:41 .DS_Store
> -rw-r--r--  1 kkwheel0 May 28 16:41 ._.DS_Store
> $ rm .DS_Store
> $ ls -la
> total 8
> drwx--  2 kkwheel  512 May 28 16:41 .
> drwxrwxrwt  7 root  wheel  512 May 28 16:41 ..
> -rw-r--r--  1 kkwheel0 May 28 16:41 ._.DS_Store
> 
> Note that bash, the shell, would not warn you about deleting files.
> This may possibly be something that rm does if used with its -i option,
> or under some other circumstances having to do with the permissions on
> the files.
> 
> -- 
> Kusalananda
> Sweden

-- 
Kusalananda
Sweden

Re: bash bug - unexpect file deleted using rm command

[Chet Ramey]

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 file, named ._.DS_Store was also erased - but 
> without warning, and I did not ask for this.  
>   Therein lies the bug.
>   I recreated two text files with different contents having those same 
> names, and repeated the steps - same problem - both files got erased with the 
> one rm command for just one of them.
> 
> Repeat-By:
>   Create those 2 files. Delete just one.
> 
> Fix:
>   probably some shell filename matching code has an error?

This doesn't have anything to do with bash. It's an artifact of how Mac OS
X treats such files (which are special to the Finder) on non-native file
systems.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: bash bug - unexpect file deleted using rm command

[Andreas Kusalananda Kähäri]

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_MACHTYPE='x86_64-redhat-linux-gnu' 
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE 
> -DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> uname output: Linux minigeek.srve.com 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue 
> Jan 15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
> 
> 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 file, named ._.DS_Store was also erased - but 
> without warning, and I did not ask for this.  
>   Therein lies the bug.
>   I recreated two text files with different contents having those same 
> names, and repeated the steps - same problem - both files got erased with the 
> one rm command for just one of them.
> 
> Repeat-By:
>   Create those 2 files. Delete just one.
> 
> Fix:
>   probably some shell filename matching code has an error?
> 
> 

What was your actual command when deleting the file(s)?  If no filename
globbing pattern was used, then I think the shell can be ruled out as
the culprit.  If a globbing pattern was used, e.g. .*DS_Store .DS_Store

$ touch .DS_Store ._.DS_Store
$ ls -la
total 8
drwx--  2 kkwheel  512 May 28 16:41 .
drwxrwxrwt  7 root  wheel  512 May 28 16:41 ..
-rw-r--r--  1 kkwheel0 May 28 16:41 .DS_Store
-rw-r--r--  1 kkwheel0 May 28 16:41 ._.DS_Store
$ rm .DS_Store
$ ls -la
total 8
drwx--  2 kkwheel  512 May 28 16:41 .
drwxrwxrwt  7 root  wheel  512 May 28 16:41 ..
-rw-r--r--  1 kkwheel0 May 28 16:41 ._.DS_Store

Note that bash, the shell, would not warn you about deleting files.
This may possibly be something that rm does if used with its -i option,
or under some other circumstances having to do with the permissions on
the files.

-- 
Kusalananda
Sweden

bash bug - unexpect file deleted using rm command

[root]

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' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE -DRECYCLES_PIDS  
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
uname output: Linux minigeek.srve.com 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue Jan 
15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

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 file, named ._.DS_Store was also erased - but 
without warning, and I did not ask for this.  
Therein lies the bug.
I recreated two text files with different contents having those same 
names, and repeated the steps - same problem - both files got erased with the 
one rm command for just one of them.

Repeat-By:
Create those 2 files. Delete just one.

Fix:
probably some shell filename matching code has an error?

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

[Chris F.A. Johnson]

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.

--
Chris F.A. Johnson, 

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

[PePa]

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?

[Greg Wooledge]

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 | $'\t' .  
> |
> 
> A Bash bug???

No.  You're inside double quotes, so you parse the content accordingly.
Inside double quotes, $ may begin a parameter expansion, or an
arithmetic expansion, and so on.  But in this case, it does not.
So the $ is just taken literally.

If you want to use something that expands to a tab inside double quotes,
try this:

tab=$'\t'
echo "$tab " | xod
echo "${tab}indented" | xod

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

[Robert Elz]

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 characters.   So in "$'...'" the $' are
just characters (though probably strictly undefined behaviour, as $ followed
by something that is not a var name (or positional or special param name)
and is not { or ( is undefined, and $ inside " is supposed to be expanded,
but cannot be here.

kre

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

[Chet Ramey]

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' .  
> |
> 
> A Bash bug???

Where's the bug? Since single quotes aren't special within double quotes,
what behavior do you expect?


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

$"\t': Bash bug or not?

[Rick Richardson]

$ echo "$LOGNAME " | xod

Dump: standard input

Offset:0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f   0123456789abcdef

: 72 69 63 6b 20 0a| rick .   |

OK!

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

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

: 09 20 0a | . .  |

OK if you *don't quote it*.



-- 
Rick Richardson rickr...@gmail.com http://rickrich1.home.comcast.net/
Linux printer drivers for JBIG (GDI printers): Konica Minolta magicolor,
  HP LaserJet, Samsung, Xerox, Lexmark, and Oki.
 http://foo2zjs.rkkda.com/
Linux tools for geocaching   http://geo.rkkda.com/
Gnome Manual Duplex http://sourceforge.net/projects/g-manual-duplex/

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

[Chet Ramey]

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 in naming this a bug:

I have a hard time seeing this as a bug.  I can run it without error after
taking your script from the link to stackexchange and making sure the
leading whitespace is tabs and there are no stray characters following the
here-document delimiters.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Noneofthebusiness Ofsomehere]

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:


https://unix.stackexchange.com/questions/359910/heredocument-error-i-cant-understand-delimited-by-end-of-file

[https://cdn.sstatic.net/Sites/unix/img/apple-touch-i...@2.png?v=32fb07f7ce26]

Heredocument error I can't understand ("delimited by end of 
file")
unix.stackexchange.com
I execute the following code in Bash: bash /dev/fd/10 10<<-'SES' cat <> 
/etc/apache2/apache2.conf # Options Indexes

Re: Bash bug

[Eduardo Bustamante]

You can do:

local var; var=$(...); ... $?

No need to make the declaration and assignment at the same time.

Re: Bash bug

[Clark Wang]

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 obviously the return value is 1.
>

``local'' itself is a command. So ``local var=value'' would usually return
0 because it _successfully_ assigns the value the the var. ``local'' would
return non-zero when there's something wrong with the syntax. For example
``local invalid.var.name'' or ``readonly var=1; local var=2''.


>
> B(){
>  return_value="$(bash -c "exit 1")"
>  echo $?
> }
>
> function B: returns 1 - as expected, the only difference to function A
> being not using a local variable to store the value.
>

Without ``local'', the value of $? would be changed by the $(...) part in
the assignment.

-clark

>
>
>
> Best regards,
>
> A happy bash user
>
>
>

Bash bug

[Weshakie Löwe]

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")"
 echo $?
}

function B: returns 1 - as expected, the only difference to function A 
being not using a local variable to store the value.




Best regards,

A happy bash user

Re: Possible bash bug?

[Reuti]

> 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 18038 17951  0 09:26 pts/14   00:00:00 bash -c ping 127.0.0.1 > 
> /home/john/console.log
> john 18039 18038  0 09:26 pts/14   00:00:00 ping 127.0.0.1
>  
> From the process hierarchy bash is the parent process of ping.
>  
> Now if I kill bash:
>  
> kill -15 18038

This kills just the specified process.

What does happen when you issue:

$ kill %1

(resp. the the number output when issuing the above command) instead?

-- Reuti


>  And check the process tree again:
>  
> UIDPID  PPID  C STIME TTY  TIME CMD
> john 17951 30467  0 09:25 pts/14   00:00:00 /bin/bash
> john 18039 1  0 09:26 pts/14   00:00:00 ping 127.0.0.1
> john 18064 17951  0 09:30 pts/14   00:00:00 ps -f
> [1]+  Terminated  bash -c "ping 127.0.0.1 > $HOME/console.log"
>  
> Bash is killed but not the child ping process. I was expecting that to be 
> killed also.
>  
> If I repeat the exact same steps with ksh –c, it does kill the ping process.
>  
> It looks like bash does a double fork or something whereas ksh does only an 
> execute without fork.
>  
> Regards,
> John
> 
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you are not the intended recipient, please note that any review, 
> dissemination, disclosure, alteration, printing, circulation, retention or 
> transmission of this e-mail and/or any file or attachment transmitted with 
> it, is prohibited and may be unlawful. If you have received this e-mail or 
> any file or attachment transmitted with it in error please notify 
> postmas...@openet.com. Although Openet has taken reasonable precautions to 
> ensure no viruses are present in this email, we cannot accept responsibility 
> for any loss or damage arising from the use of this email or attachments.

Re: Possible bash bug?

[Greg Wooledge]

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. SIGTERM) to be caught by bash
and propagated to bash's children, you need to catch it and send it
to your children.  This also means you have to run your children as
background processes and capture their PIDs.  Otherwise, if the child is
a foreground process, bash will not receive the signal until the child
exits on its own.

For example:

#!/bin/bash
unset pid
trap '[[ $pid ]] && kill $pid' EXIT
ping 127.0.0.1 >~/console.log &
pid=$!
wait

Possible bash bug?

[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 18038 17951  0 09:26 pts/14   00:00:00 bash -c ping 127.0.0.1 > 
/home/john/console.log
john 18039 18038  0 09:26 pts/14   00:00:00 ping 127.0.0.1

>From the process hierarchy bash is the parent process of ping.

Now if I kill bash:

kill -15 18038

And check the process tree again:

UIDPID  PPID  C STIME TTY  TIME CMD
john 17951 30467  0 09:25 pts/14   00:00:00 /bin/bash
john 18039 1  0 09:26 pts/14   00:00:00 ping 127.0.0.1
john 18064 17951  0 09:30 pts/14   00:00:00 ps -f
[1]+  Terminated  bash -c "ping 127.0.0.1 > $HOME/console.log"

Bash is killed but not the child ping process. I was expecting that to be 
killed also.

If I repeat the exact same steps with ksh -c, it does kill the ping process.

It looks like bash does a double fork or something whereas ksh does only an 
execute without fork.

Regards,
John


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, please note that any review, dissemination, 
disclosure, alteration, printing, circulation, retention or transmission of 
this e-mail and/or any file or attachment transmitted with it, is prohibited 
and may be unlawful. If you have received this e-mail or any file or attachment 
transmitted with it in error please notify postmas...@openet.com. Although 
Openet has taken reasonable precautions to ensure no viruses are present in 
this email, we cannot accept responsibility for any loss or damage arising from 
the use of this email or attachments.

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

[Roel Van de Paar]

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:
> > LINE='test'; DONE=0; echo ${LINE} | if grep -q 'test'; then
> DONE=1;
> > echo "DONE"; fi; echo $DONE
>
> All elements of a pipeline are executed in subshells.  A subshell cannot
> affect its parent's environment.  The `lastpipe' shell option can change
> this when job control is not active.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>



-- 

Kind Regards,
God Bless,
-- 
Roel Van de Paar, CMDBA/CMDEV Senior QA Lead, Percona
Tel: +61 2 8004 1288 (UTC+10)
Mob: +61 427 141 635 (UTC+10)
Skype: percona.rvandepaar
http://www.percona.com/services.html

Looking for Replication with Data Consistency?
Try Percona XtraDB Cluster
!

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

[Chet Ramey]

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 "DONE"; fi; echo $DONE

All elements of a pipeline are executed in subshells.  A subshell cannot
affect its parent's environment.  The `lastpipe' shell option can change
this when job control is not active.
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash bug in variable assignment/echo/grep -q

[Roel Van de Paar]

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' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE
-DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin'  -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic
uname output: Linux localhost.localdomain 3.10.0-123.13.2.el7.x86_64 #1 SMP
Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

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 "DONE"; fi; echo $DONE

Re: bash bug with read -s command

[Piotr Grzybowski]

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 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 -cursor on

 expected results:
 cursor is visible and typed keys are echoed to screen as before

 actual results:
 cursor is visible, keys are no-longer echoed to the screen until
 terminal is closed

 additional notes
 command: setterm -default cannot fix
 os: fedora 21
 bash version: bash-4.3.30-2.fc21.x86_64
 tested in various terminal emulators, and the console (alt+Fn, where
 n=1-8)

 workaround
 remove silent -s from read command

 sample script
 http://pastebin.com/EhCNaWmT

Re: bash bug with read -s command

[Chet Ramey]

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 trapped successfully
 and the cursor is un-hidden
 setterm -cursor on
 
 expected results:
 cursor is visible and typed keys are echoed to screen as before
 
 actual results:
 cursor is visible, keys are no-longer echoed to the screen until
 terminal is closed
 
 additional notes
 command: setterm -default cannot fix
 os: fedora 21
 bash version: bash-4.3.30-2.fc21.x86_64
 tested in various terminal emulators, and the console (alt+Fn, where 
 n=1-8)
 
 workaround
 remove silent -s from read command

There are a couple of things to note here.  First, it's the trap that
causes the problem: it short-circuits the normal exit path that would cause
the terminal to be cleaned up, then just calls exit instead of killing
the shell with SIGINT.  (To see why you should do that, read
http://www.cons.org/cracauer/sigint.html).  If the script died due to
SIGINT, the parent bash would notice and restore the terminal settings.

Second, you can clean this up without any changes to bash by running a
terminal cleanup command (`stty sane', `reset', whatever) in the SIGINT
trap.

If you would like to take a look at patching bash so you don't have to
modify your script, take a look at the attached patch.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/shell.c	2014-01-14 08:04:32.0 -0500
--- shell.c	2014-12-22 10:27:50.0 -0500
***
*** 74,77 
--- 74,78 
  
  #if defined (READLINE)
+ #  include readline/readline.h
  #  include bashline.h
  #endif
***
*** 910,913 
--- 912,923 
fflush (stderr);
  
+   /* Clean up the terminal if we are in a state where it's been modified. */
+ #if defined (READLINE)
+   if (RL_ISSTATE (RL_STATE_TERMPREPPED)  rl_deprep_term_function)
+ (*rl_deprep_term_function) ();
+ #endif
+   if (read_tty_modified ())
+ read_tty_cleanup ();
+ 
/* Do trap[0] if defined.  Allow it to override the exit status
   passed to us. */
*** ../bash-4.3-patched/builtins/read.def	2014-10-01 12:57:38.0 -0400
--- builtins/read.def	2014-12-22 10:48:54.0 -0500
***
*** 141,148 
  int sigalrm_seen;
  
! static int reading;
  static SigHandler *old_alrm;
  static unsigned char delim;
  
  /* In all cases, SIGALRM just sets a flag that we check periodically.  This
 avoids problems with the semi-tricky stuff we do with the xfree of
--- 141,150 
  int sigalrm_seen;
  
! static int reading, tty_modified;
  static SigHandler *old_alrm;
  static unsigned char delim;
  
+ static struct ttsave termsave;
+ 
  /* In all cases, SIGALRM just sets a flag that we check periodically.  This
 avoids problems with the semi-tricky stuff we do with the xfree of
***
*** 189,193 
SHELL_VAR *var;
TTYSTRUCT ttattrs, ttset;
-   struct ttsave termsave;
  #if defined (ARRAY_VARS)
WORD_LIST *alist;
--- 191,194 
***
*** 222,226 
USE_VAR(lastsig);
  
!   sigalrm_seen = reading = 0;
  
i = 0;		/* Index into the string that we are reading. */
--- 223,227 
USE_VAR(lastsig);
  
!   sigalrm_seen = reading = tty_modified = 0;
  
i = 0;		/* Index into the string that we are reading. */
***
*** 439,442 
--- 440,445 
  	  goto assign_vars;
  	}
+   if (interactive_shell == 0)
+ 	initialize_terminating_signals ();
old_alrm = set_signal_handler (SIGALRM, sigalrm);
add_unwind_protect (reset_alarm, (char *)NULL);
***
*** 483,487 
--- 486,493 
  	  if (i  0)
  	sh_ttyerror (1);
+ 	  tty_modified = 1;
  	  add_unwind_protect ((Function *)ttyrestore, (char *)termsave);
+ 	  if (interactive_shell == 0)
+ 	initialize_terminating_signals ();
  	}
  }
***
*** 498,502 
--- 504,511 
  	sh_ttyerror (1);
  
+   tty_modified = 1;
add_unwind_protect ((Function *)ttyrestore, (char *)termsave);
+   if (interactive_shell == 0)
+ 	initialize_terminating_signals ();
  }
  
***
*** 589,592 
--- 598,603 
  	  else
  	lastsig = 0;
+ 	  if (terminating_signal  tty_modified)
+ 	ttyrestore (termsave);	/* fix terminal before exiting */
  	  CHECK_TERMSIG;
  	  eof = 1;
***
*** 979,982 
--- 990,1007 
  {
ttsetattr (ttp-fd, ttp-attrs);
+   tty_modified = 0;
+ }
+ 
+ void
+ read_tty_cleanup ()
+ {
+   if (tty_modified)
+ ttyrestore (termsave);
+ }
+ 
+ int
+ read_tty_modified ()
+ {
+   return (tty_modified);
  }
  
*** 

bash bug with read -s command

[Richard W. Marsden]

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 -cursor on

expected results:
cursor is visible and typed keys are echoed to screen as before

actual results:
cursor is visible, keys are no-longer echoed to the screen until
terminal is closed

additional notes
command: setterm -default cannot fix
os: fedora 21
bash version: bash-4.3.30-2.fc21.x86_64
tested in various terminal emulators, and the console (alt+Fn, where
n=1-8)

workaround
remove silent -s from read command

sample script
http://pastebin.com/EhCNaWmT

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

[Dan Douglas]

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 simple, in tab completion,
  the text placed into the buffer should be in the same format that the
  read is expecting, so if -r is in effect for the read operation, the
  the filename should be added to the buffer unquoted.
 
 This seems like an awfully specific case (-r in effect, one or fewer
 variables specified) to change readline for.  I question whether it's of
 general interest.
 
 
I'm generally interested in what read with (or without) -r combined with -e 
even means. 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.

-- 
Dan Douglas

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

[Chet Ramey]

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' Bourne shells ever had it.  It may be the case that
it was easier to use \ to enter characters that were special to word
splitting, since without it it's very difficult to read values containing
spaces when using more than one variable.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Chet Ramey]

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 lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Dan Douglas]

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 how the characters are processed after being
 read.


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). Long ago I assumed read str was equivalent to read -r $'str'
based upon what the manual says.

BTW I like how show-mode-in-prompt On together with read -ep prompt shows
the indicator. That's a nice touch.
--
Dan Douglas

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

[Chet Ramey]

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 up calling readline N times for every N-1 backslash-escaped
newlines.  If -r is supplied it doesn't need to do anything out of the
ordinary for \newline.

In terms of backslash escaping characters in the line read, backslash
isn't really special to readline, it's just mapped to self-insert.  You
still have to use quoted-insert to insert characters that are bound to
line editing commands.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Chet Ramey]

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 in the same format that the
 read is expecting, so if -r is in effect for the read operation, the
 the filename should be added to the buffer unquoted.

This seems like an awfully specific case (-r in effect, one or fewer
variables specified) to change readline for.  I question whether it's of
general interest.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash bug - in read -e -r var

[Daniel A. Gauthier]

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 -r is in effect for the read operation, the
the filename should be added to the buffer unquoted.  This is gonna look
something like replacing
updatebuffer(wordstart,cursorposition,quotechars(expandedcompletion));

with

updatebuffer(wordstart,cursorposition,(modeCONVERTBACKSLASH?quotechars(expandedcompletion):expandedcompletion));

This was sent here as suggested by your bug reporting under the guise of
philosophical bugs.

Thank you for your consideration,
(I'll probably fix this myself someday, but it could be years - I get
kinda busy)

Daniel A. Gauthier
Service Manager
Empire Industries, Inc.
Midland, MI  48640

1-989-835-2151

Dan

Re: possible bash bug - 'history'

[Chris Down]

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 suffices considering the
intention.

 What do folks think?

I can't imagine myself ever using it, but it seems like a reasonable feature
request to me. If POSIX doesn't say anything about it, I'm in favour of
implementing it in the most intuitive way (which, I think, is the way
proposed).


pgp3N_FdiaPhT.pgp
Description: PGP signature

Re: possible bash bug - 'history'

[Chet Ramey]

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 history, or a BASH variable ( to my knowledge it does not exist )
 
 # echo blah_blah ; echo $THIS_CMD_LINE ( or history -n0 )
 
 
 I can do this in ksh:
 # hist -l -n0
 ( will output the same, in this case hist -l -n0 )

This is an interesting feature request.  Right now, -0 is treated
the same as -1 on the assumption that nobody wants to operate on the
actual fc command itself, and 0 is treated the same as -0 because that
makes sense.

It's not really a Posix issue because Posix doesn't mention 0 (only
positive and negative integers), and different shells claiming posix
compatibility do different things.  And there's internally inconsistent
behavior: fc -l -n0 and fc -l -n 0 do different things in ksh93, for
instance.

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.)

What do folks think?

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash bug interpolating delete characters

[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
 002
 000 del  sp  nl
 003
 000  sp del  nl
 003
 
 however with bash 4.1 and bash 4.2.20, the output is only:
 
 000 del  nl
 002
 000  sp  nl
 002
 000  sp  nl
 002
 
 ... so in the second and third line, the delete character magically
 disappears. Neither OS nor locale seem to influence this. Using a delete
 character directly in the script instead of $del also has no impact, either.

It's a case of one part of the code violating assumptions made by (and
conditions imposed by) another.  Try the attached patch; it fixes the
issue for me.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-20120427/subst.c	2012-04-22 16:19:10.0 -0400
--- subst.c	2012-05-07 16:06:35.0 -0400
***
*** 8160,8163 
--- 8160,8171 
  	  dispose_word_desc (tword);
  
+ 	  /* Kill quoted nulls; we will add them back at the end of
+ 	 expand_word_internal if nothing else in the string */
+ 	  if (had_quoted_null  temp  QUOTED_NULL (temp))
+ 	{
+ 	  FREE (temp);
+ 	  temp = (char *)NULL;
+ 	}
+ 
  	  goto add_string;
  	  break;
***
*** 8568,8572 
if (quoted  (Q_HERE_DOCUMENT|Q_DOUBLE_QUOTES))
  	tword-flags |= W_QUOTED;
!   if (had_quoted_null)
  	tword-flags |= W_HASQUOTEDNULL;
list = make_word_list (tword, (WORD_LIST *)NULL);
--- 8576,8580 
if (quoted  (Q_HERE_DOCUMENT|Q_DOUBLE_QUOTES))
  	tword-flags |= W_QUOTED;
!   if (had_quoted_null  QUOTED_NULL (istring))
  	tword-flags |= W_HASQUOTEDNULL;
list = make_word_list (tword, (WORD_LIST *)NULL);
***
*** 8599,8603 
  	  if (word-flags  W_NOEXPAND)
  	tword-flags |= W_NOEXPAND;
! 	  if (had_quoted_null)
  	tword-flags |= W_HASQUOTEDNULL;	/* XXX */
  	  list = make_word_list (tword, (WORD_LIST *)NULL);
--- 8607,8611 
  	  if (word-flags  W_NOEXPAND)
  	tword-flags |= W_NOEXPAND;
! 	  if (had_quoted_null  QUOTED_NULL (istring))
  	tword-flags |= W_HASQUOTEDNULL;	/* XXX */
  	  list = make_word_list (tword, (WORD_LIST *)NULL);

Re: Bash bug interpolating delete characters

[John Kearney]

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

 however with bash 4.1 and bash 4.2.20, the output is only:

 000 del  nl
 002
 000  sp  nl
 002
 000  sp  nl
 002

 ... so in the second and third line, the delete character magically
 disappears. Neither OS nor locale seem to influence this. Using a delete
 character directly in the script instead of $del also has no impact, either.
 It's a case of one part of the code violating assumptions made by (and
 conditions imposed by) another.  Try the attached patch; it fixes the
 issue for me.

 Chet

It also works for me.

  $del${a#x} =[$'\177']
   $del${a%x}=[$' \177']
   $del${a:0:0}=[$' \177']
   ${del}${a:0:0}=[$' \177']
  ${del:0:1}${a#d}   =[$'\177x']
  ${del:0:1} ${a#d}  =[$'\177 x']
  ${del:0:1} ${a:+}  =[$'\177 ']
  $del ${a#x}=[$'\177 ']
   $del${a:0:0}  =[$' \177']
   $del${a}  =[$' \177x']
   ${del:0:1}${a:0:0}=[$' \177']
  ${del:0:1}${a#x}   =[$'\177']
  ${del:0:1} ${a#x}  =[$'\177 ']
   $del${a#x}=[$' \177']
   $del${a:0:0}  =[$' \177']
   $del  =[$' \177']
   ${del:0:1}${a}=[$' \177x']
  ${del:0:1} ${a}=[$'\177 x']
  ${del:0:1} ${a:-}  =[$'\177 x']

Re: Severe Bash Bug with Arrays

[Maarten Billemont]

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

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 something that is stupid and not thought through. Doing evil has harmful 
side effects. It's not cool to be evil, it's short-sighted.

 But reality is things like that save me time in typing in stuff or writing
 maint scripts on my machine -- they aren't meant for handling user input.
 
 They take hand editing to gen the paths I want and don't take user input,
 so it's a specialized usage in that case

It's fine to do short-sighted hacks on the prompt, where you know your input 
well and will notice breakage so that you can recover.

It's not fine to do said things in scripts that run on unpredictable input and 
where you don't always notice breakage until it's caused irreparable harm.  I 
don't really care what lame justifications you come up with to try and justify 
broken system code to yourself, just don't try to convince us with them.

 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 example code I provided.  ${b[@]}  Will NOT
 work as a replacement for [*].  It isn't not BETTER, it is DIFFERENT.
 That's why there are both.

I didn't say never to use ${b[*]}.  I said it's usually not what anyone 
wants.  It's mostly only useful for merging arrays into a single string such as 
for user display of said array.  I explained that.  You are correct, of course, 
there are two syntaxes, they both do something different (when quoted), and 
that's fine.  They each have their use case.

What I *did* say, is never to use ${b[*]}.  And it also so happens that ${b[@]} 
is not different from ${b[*]}.  And I stick with that point.  Never use 
unquoted expansion of arrays, not with [*], not with [@].

 your array like above, you then follow up by re-splitting the whole thing 
 using standard wordsplitting, not to mention pathname expanding the 
 resulting words.
 
 I followed up?  I don't understand this.

When you leave ${b[*]} unquoted, you expand each element of the array, then ask 
bash to split the whole thing, and then pathname expand the result.  Not only 
did you just throw away any distinction between the different array elements, 
you also made an entirely new distinction (whitespace), and then you're asking 
bash to search the filesystems for any pathnames that match each of the words.  
Seriously, nobody, ever, wants, this.  If they did, they'd have used a string 
instead.  And even then I question the sanity behind it.  Word-splitting is 
useful in a primitive POSIX shell that has no concept like arrays etc. to 
compensate.  In bash, it is the major cause of bugs, and best avoided.

 I would assume they'd have the
 intelligence to know when to use * or @ and I wouldn't have to talk down to 
 them
 and cover basics.

I can't help notice the slight irony in my having to explain to you the 
necessity of quotes with array expansion.

 You should always recommend the ${b[@]} variant.
 
 I shouldn't ALWAYS do anything.  It's dangerous.
 You can do so for your examples... It won't work in the next
 two any more than the last one of the previous...

What?

Anyway, think about this: An array holds elements in a way that each is 
separated from the other.  To put these elements in an array is to want each 
element to be distinct from the others.  Therefore, the default way of 
expanding these elements should preserve that distinction.

Only in rare cases is the actual INTENT of the author to MERGE these elements 
into a single unit, a single string, thus throwing away the distinction between 
the elements.  And in THOSE cases and those cases ALONE should the author use 
${array[*]}.  So yes, always recommend ${b[@]}, unless you know for a fact 
that the author is looking to merge the elements.

 sort an arg list:
 
  args=-dpi -xinerama -clipboard -unixkill -nowinkill -ac +bs -fp 
  -multiwindow
 
  readarray -t dflts ( a=( $args ); IFS=$'\n'; echo ${a[*]#?}|sort -k1.2 )
 
  printf   defaults=(%s) ${dflts[*]}
 
  defaults=(-ac +bs -clipboard -dpi -fp -multiwindow -nowinkill -unixkill 
 -xinerama)

... What are you trying to prove?  That with a very specific sent of input 
values you can do some ugly and hacky mangling involving arrays and 
wordsplitting to sort a word-list?  Why are you even USING arrays here at all?  
There's no point.  Just to replace spaces with newlines?

Also, you're doing a lot of 

Re: Severe Bash Bug with Arrays

[Linda Walsh]

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 something that is stupid and not thought through. Doing


 evil has harmful side effects. It's not cool to be evil, it's short-sighted.
---
You have a very twisted view of evil.



code to yourself, just don't try to convince me with them.


---
There is no need to convince someone with your views of anything.




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.



I didn't say never to use ${b[*]}. 
What I *did* say, is never to use ${b[*]}.


===
Uh, why do you bother to write about the horrors of such usage, when the
purpose of my test cases, was to progressively show effects.

When I echoed out the unquoted part, the intervening white space was removed...
To get the original text (with embedded line feeds, proving the file was
stored in the var), one must quote it.







Anyway, think about this: An array holds elements in a way that each is separated 


from the other.  To put these elements in an array is to want each element to be 

distinct from the others.  Therefore, the default way of expanding these elements 


should preserve that distinction.

==

When I want to preserve that distinction, I usually try something like
printq save $typeset -p arrayname)..
then later
eval $save to recover the array.

That's not what the original author was asking about.



args=-dpi -xinerama -clipboard -unixkill -nowinkill -ac +bs -fp -multiwindow
readarray -t dflts ( a=( $args ); IFS=$'\n'; echo ${a[*]#?}|sort -k1.2 )
printf   defaults=(%s) ${dflts[*]}

 defaults=(-ac +bs -clipboard -dpi -fp -multiwindow -nowinkill -unixkill 
-xinerama)


... What are you trying to prove?  That with a very specific sent of input values you 



can do some ugly and hacky mangling involving arrays and wordsplitting to sort 
a word-list?



  Why are you even USING arrays here at all?  There's no point.  Just to 
replace spaces



with newlines?


---
	The original args are in the format they were originally needed in to be passed 
to a program.  I wanted to sort them alphabetically regardless of +/-,   then 
pass them to the program.  I took the existing input, sorted it, then restored 
it to the order needed by the program.


	The point is you know nothing about code other people deal with -- presuming 
that your rules apply everywhere is insulting and invasive.  Such
behaviors need to be dealt with like invasive weeds or they take over the 
garden.  Examples are rampant.



Also, you're doing a lot of really bad stuff here. 


---
Then, from you, I know I am doing well.


Might I point out that you're stripping the leading - and + from your 



arguments and not putting them back?  I don't know where you got the output



you claim from, but the real output has lost the first character of each word.


---
Umm...no.. didn't you READ the output you idjit**!  The output didn't
lose information.  I sorted by -k1.2 (1st field second char), that doesn't 
strip. (**-Inuyasa-ism).



% args=-dpi -xinerama -clipboard -unixkill -nowinkill -ac +bs -fp -multiwindow
% readarray -t dflts ( a=( $args ); IFS=$'\n'; echo ${a[*]#?}|sort -k1.2 )
% printf   defaults=(%s) ${dflts[*]}
  defaults=(-ac +bs -clipboard -dpi -fp -multiwindow -nowinkill -unixkill 
-xinerama)

---
The output is staring you in the face... the + goes with bs --
hmmm...  it's backing store, honest!



Want to create pathnames using bash's /path/{}/  feature and have the paths
in an array (for simple paths):


a=(lib tmp bin share)
(export IFS=,;eval echo /usr/{${a[*]}})

/usr/lib /usr/tmp /usr/bin /usr/share


Don't do this.  You're injecting strings into bash code, and then evaluating that code. 


---
	Oh my gawd,  you mean like DATA as OBJECTS??  The basis for object oriented 
code?  NOT THAT Mr. Wizard!  Anything but that!




Ignoring the security aspect, this code will break for elements that contain commas 



or braces or quotes or newlines.  And you know what, yes, it's perfectly fine 
for



filenames to contain those.  It's not fine for your code to break on them.



I am a MAJOR user of those.. when my stuff doesn't work I eat the doodoo -- 
sometimes I go back to more primitive.





Grow up, use a loop.  It really doesn't hurt that much.


---
	If you don't know how to do things and know all of their pitfalls, how will you 
grow up?  If you prevent people from making their own mistakes, how will they 
grow -- they don't.  Doesn't mean you don't tell them, but to go off and preach 
at them how patently absurd to think that will accomplish anything.



C'est la vi...


vie ;-)

Fwd: Bash bug interpolating delete characters

[Chet Ramey]

---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 4.1 and bash 4.2.20, the output is only:

000 del  nl
002
000  sp  nl
002
000  sp  nl
002

... so in the second and third line, the delete character magically 
disappears. Neither OS nor locale seem to influence this. Using a delete 
character directly in the script instead of $del also has no impact, 
either.

Feel free to post this to gnu.bash.bug - unfortunately I don't have a spam 
protected email address at hand right now.

Thanks for looking at this!

Yours, Rüdiger.

The information included in this e-mail and any files transmitted with it is 
strictly confidential and may be privileged or otherwise protected from 
disclosure. If you are not the intended recipient, please notify the sender 
immediately by e-mail and delete this e-mail as well as any attachment from 
your system. If you are not the intended recipient you are not authorized to 
use and/or copy this message and/or attachment and/or disclose the contents to 
any other person.
---End Message---

Re: Fwd: Bash bug interpolating delete characters

[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=
imadev:~$ echo  $del$b | od -ta
000   sp del  nl
003
imadev:~$ echo  $del${b} | od -ta
000   sp del  nl
003
imadev:~$ echo  $del${b#x} | od -ta
000   sp del  nl
003
imadev:~$ echo  $del${a#x} | od -ta
000   sp  nl
002

Bash 4.2.24.

Re: Fwd: Bash bug interpolating delete characters

[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 included.

 imadev:~$ del=$'\x7f' a=x b=
 imadev:~$ echo  $del$b | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${b} | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${b#x} | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${a#x} | od -ta
 000   sp  nl
 002

 Bash 4.2.24.

Also Confirmed, but my output is a bit wackier.
printf %q seems to get confused, and do invalid things as well.

the \x7f becomes a \

function printTests {
while [ $# -gt 0 ]; do
printf%-20s=[%q]\n${1} $(eval echo ${1})
shift
done
}

a=x
del=$'\x7f'
printTests '$del${a#x}' '$del ${a#x}' ' $del${a#x}' ' $del${a%x}'
printTests ' $del${a:0:0}' ' $del${a:0:0}' ' $del${a:0:0}'
printTests ' $del${a}' ' $del' ' ${del}${a:0:0}' '
${del:0:1}${a:0:0}'
printTests ' ${del:0:1}${a}' '${del:0:1}${a#d}' '${del:0:1}${a#x}'
printTests ' ${del:0:1} ${a}' '${del:0:1} ${a#d}' '${del:0:1} ${a#x}'

output
$del${a#x}=[$'\177']
$del ${a#x}   =[\ ]
 $del${a#x}   =[\ ]
 $del${a%x}   =[\ ]
 $del${a:0:0} =[\ ]
 $del${a:0:0} =[$' \177']
 $del${a:0:0}   =[$' \177']
 $del${a} =[$' \177x']
 $del =[$' \177']
 ${del}${a:0:0}   =[\ ]
 ${del:0:1}${a:0:0}=[\ ]
 ${del:0:1}${a}   =[$' \177x']
${del:0:1}${a#d}  =[$'\177x']
${del:0:1}${a#x}  =[$'\177']
 ${del:0:1} ${a}  =[$' \177 x']
${del:0:1} ${a#d} =[$'\177 x']
${del:0:1} ${a#x} =[\ ]

Re: Fwd: Bash bug interpolating delete characters

[John Kearney]

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 included.

 imadev:~$ del=$'\x7f' a=x b=
 imadev:~$ echo  $del$b | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${b} | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${b#x} | od -ta
 000   sp del  nl
 003
 imadev:~$ echo  $del${a#x} | od -ta
 000   sp  nl
 002

 Bash 4.2.24.

 Also Confirmed, but my output is a bit wackier.
 printf %q seems to get confused, and do invalid things as well.

 the \x7f becomes a \
disregard the comment about printf its just escaping the space.

 function printTests {
 while [ $# -gt 0 ]; do
 printf%-20s=[%q]\n${1} $(eval echo ${1})
 shift
 done
 }

 a=x
 del=$'\x7f'
 printTests '$del${a#x}' '$del ${a#x}' ' $del${a#x}' ' $del${a%x}'
 printTests ' $del${a:0:0}' ' $del${a:0:0}' ' $del${a:0:0}'
 printTests ' $del${a}' ' $del' ' ${del}${a:0:0}' '
 ${del:0:1}${a:0:0}'
 printTests ' ${del:0:1}${a}' '${del:0:1}${a#d}' '${del:0:1}${a#x}'
 printTests ' ${del:0:1} ${a}' '${del:0:1} ${a#d}' '${del:0:1} ${a#x}'

 output
 $del${a#x}=[$'\177']
 $del ${a#x}   =[\ ]
  $del${a#x}   =[\ ]
  $del${a%x}   =[\ ]
  $del${a:0:0} =[\ ]
  $del${a:0:0} =[$' \177']
  $del${a:0:0}   =[$' \177']
  $del${a} =[$' \177x']
  $del =[$' \177']
  ${del}${a:0:0}   =[\ ]
  ${del:0:1}${a:0:0}=[\ ]
  ${del:0:1}${a}   =[$' \177x']
 ${del:0:1}${a#d}  =[$'\177x']
 ${del:0:1}${a#x}  =[$'\177']
  ${del:0:1} ${a}  =[$' \177 x']
 ${del:0:1} ${a#d} =[$'\177 x']
 ${del:0:1} ${a#x} =[\ ]

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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
 and cover basics.

Oh, you would be amazed and astonished.  I've learned never to assume
a person possesses advanced knowledge, when it comes to programming
questions.

  a=(lib tmp bin share)
  (export IFS=,;eval echo /usr/{${a[*]}})
 /usr/lib /usr/tmp /usr/bin /usr/share
 
 Anything else you wanna tell me NEVER/ALWAYS to do?

NEVER use eval plus a brace expansion to generate a list.  That's just
freakin' evil.  And unsafe:

imadev:~$ a=(lib tmp bin share '`date`')
imadev:~$ (export IFS=,;eval echo /usr/{${a[*]}})
/usr/lib /usr/tmp /usr/bin /usr/share /usr/Fri Apr 27 08:25:49 EDT 2012

(Replace `date` with whatever evil command you think is likely to be
put into the array by a malicious user.)


Alternative 1:
a=(lib tmp bin share)
echo ${a[@]/#//usr/}

Alternative 2:
a=(lib tmp bin share)
printf /usr/%s  ${a[@]}

Re: Severe Bash Bug with Arrays

[Linda Walsh]

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 /usr/Fri Apr 27 08:25:49 EDT 2012



There can be lots of such problems... I tried it on larger dirs.. parens
quote...all sorts of probs... tried embedded print %q ..etc

But reality is things like that save me time in typing in stuff or writing
maint scripts on my machine -- they aren't meant for handling user input.

They take hand editing to gen the paths I want and don't take user input,
so it's a specialized usage in that case




Alternative 1:
a=(lib tmp bin share)
echo ${a[@]/#//usr/}

Alternative 2:
a=(lib tmp bin share)
printf /usr/%s  ${a[@]}



---
good points
But I was pointing out that [*] has its place ... I use [@] alot
more often than [*], but will use [*], though a bit irregularly,
when I want to get the # of items in an array (where either would work)..
though I could make a case if it was worth anything to me that #..@ return
# items and #...[*] return total length of all items... but I don't really
careand it would break all my usages of #..[*]... ;-)

C'est la vi...

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

[(Lnda Wlsh w/faked addr )]

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 one person [sic].»   I am no more likely to use the 
same style with my mom than I would with a convicted killer, would you?


More often than not if you've read my past replies, my replies will be 
colored with the flavor of the note that was written to me.  On a good day,

it will be a toned down version of the flavor, on a less good day, it might
be an intensified version of the tone   Depends on how many times I 
revise it.   That response was my 5th revision...  If you wanted acerbic,

my first reply would have been much more appropriate (and immature).

I tend to find people who auto-judge all content from a person based on 
responses to annoying people, more than a bit immature given that human 
interactions are highly contextual.  And I mean immature -- in the sense 
that they seem to think human responses are 'robotic or preprogrammed', 
and haven't yet learned that humans are not machines.


It takes dozens of notes from the same person before I begin to 
recognize their pervasive style, and THEN might start remembering their 
name.  But usually I won't remember who wrote something by the time I 
read their next note -- unless they have a pervasive style that I notice 
over time, or have a protracted discussion with them.


Hopefully you will get this, on the off chance that you haven't 
auto-muted yourself due to any posting you've ever made in the past that 
might have offended someone. ;^).



Linda

Re: Severe Bash Bug with Arrays

[Maarten Billemont]

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 one single string (argument), concatenating the elements 
using the first character of IFS.
${b[*]} # Never do this.  On top of throwing away the usefulness of your array 
like above, you then follow up by re-splitting the whole thing using standard 
wordsplitting, not to mention pathname expanding the resulting words.

${b[@]} # Expands each array element as a separate argument, protecting it 
from wordsplitting and pathname expansion mutilation.
${b[@]} # Identical to and just as broken as ${b[*]}.  Never do this.

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. 
for displaying elements to a user:
dirs=(*/)
(IFS=,; echo The dirs are: ${dirs[*]})

But anyway, that's an aside from this topic, which has very little to do with 
this.

smime.p7s
Description: S/MIME cryptographic signature

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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. for displaying elements to a user:
 dirs=(*/)
 (IFS=,; echo The dirs are: ${dirs[*]})
 
 But anyway, that's an aside from this topic, which has very little to do with 
 this.

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

Re: Severe Bash Bug with Arrays

[DJ Mills]

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() { printf '%d args:' $#; printf ' %s' $@; echo; }

args ${array[@]}

Re: Severe Bash Bug with Arrays

[Linda Walsh]

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 example code I provided.  ${b[@]}  Will NOT
work as a replacement for [*].  It isn't not BETTER, it is DIFFERENT.
That's why there are both.

your array like above, you then follow up by re-splitting the 
whole thing using standard wordsplitting, not to mention pathname 
expanding the resulting words.





I followed up?  I don't understand this.  I gave a progressive example
that showed the results at each step.  It wasn't a canned solution for
the poster's problem, it was a different method of looking at the problem
that they could apply using whatever modifications they would need for their
example.   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
and cover basics.



${b[@]} # Expands each array element as a separate argument, 



protecting it from wordsplitting and pathname expansion mutilation.



${b[@]} # Identical to and just as broken as ${b[*]}.  Never do this.



No._NEVER_ USE ${b[@]} when you want the IFS inserted between
elements.   It doesn't work.  (I wish BASH had an OFS, that worked for
such cases as well as other expansions), but with the given system, '@' is
totally unacceptable to suggest when one wants to create an expression with
braces that bash can automatically expand.


You should always recommend the ${b[@]} variant.



I shouldn't ALWAYS do anything.  It's dangerous.
You can do so for your examples... It won't work in the next
two any more than the last one of the previous...


sort an arg list:

 args=-dpi -xinerama -clipboard -unixkill -nowinkill -ac +bs -fp -multiwindow

 readarray -t dflts ( a=( $args ); IFS=$'\n'; echo ${a[*]#?}|sort -k1.2 )

 printf   defaults=(%s) ${dflts[*]}

  defaults=(-ac +bs -clipboard -dpi -fp -multiwindow -nowinkill -unixkill 
-xinerama)


Want to create pathnames using bash's /path/{}/  feature and have the paths
in an array (for simple paths):

 a=(lib tmp bin share)
 (export IFS=,;eval echo /usr/{${a[*]}})
/usr/lib /usr/tmp /usr/bin /usr/share



Anything else you wanna tell me NEVER/ALWAYS to do?

(contrarian)

Re: Severe Bash Bug with Arrays

[Mike Frysinger]

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 part.

Re: Severe Bash Bug with Arrays

[Chet Ramey]

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 a subshell. See
 http://mywiki.wooledge.org/BashPitfalls#grep_foo_bar_.7C_while_read_-r.3B_do_.28.28count.2B-.2B-.29.29.3B_done.

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.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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 response that mentioned that, but when I
was testing it, it didn't seem to work.

The manual says job control has to be off, so I did it as a script:

imadev:~$ cat foo
#!/bin/bash
set +m
shopt -s lastpipe
echo hi | read foo
echo $foo
printf '%s\n' some words | while read -r line; do myarray+=($line); done
printf '%s ' ${myarray[@]}; echo
imadev:~$ ./foo

 
imadev:~$ /bin/bash -c 'echo $BASH_VERSION'
4.2.20(8)-release

This is the first time I've ever attempted to use lastpipe, so I'm not
sure what's wrong.

Re: Severe Bash Bug with Arrays

[Chet Ramey]

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 subshell.
 
 I actually started writing a response that mentioned that, but when I
 was testing it, it didn't seem to work.
 
 The manual says job control has to be off, so I did it as a script:
 
 imadev:~$ cat foo
 #!/bin/bash
 set +m
 shopt -s lastpipe
 echo hi | read foo
 echo $foo

z4.local(1)$ cat x3
#! ../bash-4.2-patched/bash
shopt -s lastpipe

echo foo | read bar
echo $bar
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

The set +m doesn't matter, since scripts do not have job control enabled
by default.  Adding it doesn't change the behavior.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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.

imadev:/var/tmp/bash/bash-4.2$ cat ~/foo
#!/bin/bash
shopt -s lastpipe
echo hi | read foo
echo $foo
imadev:/var/tmp/bash/bash-4.2$ ./bash -c 'echo $BASH_VERSION'
4.2.24(9)-release
imadev:/var/tmp/bash/bash-4.2$ ./bash ~/foo

Re: Severe Bash Bug with Arrays

[Chet Ramey]

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 them.  No change.

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.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Severe Bash Bug with Arrays

[Roman Rakus]

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

I grabbed patches 21-24 and applied them.  No change.

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.

Chet

On Fedora 16 it works as expected.
$ rpm -q bash
bash-4.2.24-1.fc16.x86_64

RR

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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
 bash-4.2.24-1.fc16.x86_64

It fails on HP-UX 10.20 in bash 4.2.20 and 4.2.24 (from source).
It also fails on OpenBSD 5.0 using bash 4.2.10 from ports.  Since those
are the first two cases I tried, I was quite puzzled.

It works on Debian 6.0 in bash 4.2.10 (from source), which I just happened
to have lying around.  So far everyone has reported success on any Linux
system, so that doesn't surprise me.

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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
cyclops:/var/tmp/bash/bash-4.2$ cat ~/foo
#!/bin/bash
shopt -s lastpipe
echo hi | read foo
echo $foo
cyclops:/var/tmp/bash/bash-4.2$ ./bash ~/foo

cyclops:/var/tmp/bash/bash-4.2$ uname -a
OpenBSD cyclops.wooledge.org 5.0 GENERIC.MP#63 amd64

Re: Severe Bash Bug with Arrays

[Chet Ramey]

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 the appropriate code in
execute_cmd.c:execute_pipeline.  Maybe the call to move_to_high_fd
fails.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Severe Bash Bug with Arrays

[Ted Okuzumi]

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 it fails when the array+=( )  is used.  It doesn't fail on other
commands that I've seen.

This is why I am saying it is definitely a bug.  Do you not agree?

Thanks,
Ted

On Tue, Apr 24, 2012 at 10:23 PM, Clark Wang clark.w...@oracle.com wrote:

 On Wed, Apr 25, 2012 at 07:21, Ted Okuzumi tedokuz...@gmail.com wrote:

 I am writing this e-mai to report to report a bug in bash.

 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-unknown-linux-gnu'
 -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale'
 -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib
 -g \
 -O2
 uname output: Linux concour5 2.6.18-274.3.1.el5xen #1 SMP Tue Sep 6
 20:57:11 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
 Machine Type: x86_64-unknown-linux-gnu

 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 a subshell. See
 http://mywiki.wooledge.org/BashPitfalls#grep_foo_bar_.7C_while_read_-r.3B_do_.28.28count.2B-.2B-.29.29.3B_done.



 Works:
 while read -r line; do myarray+=( $line ); done  (echo $mydata)

Re: Severe Bash Bug with Arrays

[Greg Wooledge]

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 appear to understand the issue here.  Each command in a pipeline
is run in a separate subshell.  That means echo runs in its own subshell,
and the entire while loop runs in its own subshell.

In the first example, you are populating a variable inside this subshell.

After the pipeline ends, that subshell is gone, and so is the variable
that you populated.

In the second example, you are simply writing things to stdout.  You are
not populating variables that need to persist beyond the lifespan of the
subshell.

 Then it works.  To pipe output into a while statement works, normally,
 however it fails when the array+=( )  is used.  It doesn't fail on other
 commands that I've seen.
 
 This is why I am saying it is definitely a bug.  Do you not agree?

I do not agree.

Re: Severe Bash Bug with Arrays

[DJ Mills]

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

 Then it works.  To pipe output into a while statement works, normally,
 however it fails when the array+=( )  is used.  It doesn't fail on other
 commands that I've seen.

 This is why I am saying it is definitely a bug.  Do you not agree?

 Thanks,
 Ted



It is NOT a bug. POSIX specifies this behavior. The echo is still run
in a subshell...

The issue is that commands in a pipeline are run in a subshell. This
means that assignments and changes in PWD do not persist afterwards.
See http://mywiki.wooledge.org/BashFAQ/024.

The lastpipe shopt will work, as discussed before. The other options
are process substitution, or (POSIXly) a fifo.

Examples:

# Process substitution:
while read -r line; do
  array+=($line)
done  (some_command)


# FIFO:
mkfifo myfifo || exit
trap 'rm -f myfifo' EXIT

some_command  myfifo 
while read -r line; do
  array+=($line)
done  myfifo


# Or, since it's a string you're using in your example, you could use
a here string or here document
while read -r line; do array+=($line); done $mydata

while read -r line; do array+=($line); done EOF
$mydata
EOF

mapfile, with bash4, is also an option for this particular case.