(no subject)

[wang]

网络推广优惠活动,

新浪竟价返点45.SOHU竟价返点35.TOM竟价返点45.

百度竟价返点35.3721竟价78折.中搜竟价75折

新浪,SOHU,163固定排名65折.TOM固定65折.

通用网址6折，3721实名65折，百度火暴地带75折


HAO123首页广告文字连接

国际域名50,.CN域名40


QQ314544899 [EMAIL PROTECTED]

电话:010--86657920 张先生


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

[bash-5.2] array assignment caused bash to stop saving history

[Clark Wang]

Very often Bash 5.2 would suddenly stop saving command history which
has been confusing me for quite some time. Today I did some debugging
and came up with the following minimal scenario to reproduce the
problem.


$ bash --version
GNU bash, version 5.2.0(18)-beta (x86_64-apple-darwin21.5.0)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ bash --norc
bash-5.2$ true 111
bash-5.2$ history 2
  501  true 111
  502  history 2
bash-5.2$ arr=()
bash-5.2$ true 222
bash-5.2$ history 2
  502  history 2
  503  arr=()
bash-5.2$


As we can see, after `arr=()' the command `true 222' is not saved to history.

-clark

Re: Nested expansion in heredoc fails

[wang yuhang]

Hello 

In bash-5.2, There is one modification: fix to expand $'...' and 
$"..." in certain word expansions while expanding lines of here-document data


This modification has been changed when dealing with '$(', It seems 
to have missed the right bracket. Maybe we should add this bracket.


I hope this patch can fix your problem

fix.patch
Description: Binary data

Re: Nested expansion in heredoc fails

[wang yuhang]

On 12/13/22 12:42 PM, wang yuhang wrote:> This modification has 
been changed when dealing with '$(', It seems  > to have missed the 
right bracket. Maybe we should add this bracket.
It seems that there is something wrong with this patch, It's true that my brain 
is not very good late at night. Please ignore it

The memory occupied by bash has been increasing due to the fork bomb

[wang yuhang]

Hello !

I am now doing a test on the fork bomb with the command `:(){:|:&};:` and 
set `ulimit - c 1000`. And everything was well in bash-5.0, but there was a 
problem in bash-5.1. 


The main performance is that the system memory has been rising, and then the 
kernel appears the oom, I found that the memory increase may be caused by 
the following reasons:


First, systemd will send a sigterm to bash, but in bash-5.1, the bash process 
will not be killed. this was caused by a change in bash 5.1. The modified 
change information is as follows
```
sss. Fix a bug where receiving SIGTERM from a different process while readline 
was active could cause the shell to terminate
```


Second, When bash fork is a child process, it always creates a memory to 
manage the job, even if the maximum number set by the ulimit command is reached
```
int stop_pipeline(async, deferred)
int async;
COMMAND *deferred;
{
    ... ...
    if (js.jobslots == 0) {
        ... ...
        jobs = (JOB **)xmalloc(js.j_jobslots * sizeof(JOB 
*));
        ... ...
    }
    ... ...
    if (i == js.jobslots) {
        ... ...
        jobs = (JOB **)xrealloc(js.j_jobslots * sizeof(JOB 
*));
        ... ...
    }

}
```


After my own positioning, the above is probably the reason for the memory 
increase. Could you tell me how to avoid or optimize memory increase ?


thanks ??

Re: The memory occupied by bash has been increasing due to the fork bomb

[wang yuhang]

> First, systemd will send a sigterm to bash, but in bash-5.1, the bash 
process will not be killed. this was caused by a > > > change in bash 
5.1. The modified change information is as follows
> ```
> sss. Fix a bug where receiving SIGTERM from a different process while 
readline was active could cause the shell to terminate
> ```

Sorry, it's wrong. The sigterm signal is sent by bash instead of 
systemd, Relevant log information is as follows


```
Mar 10 08:52:58 localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: 
comm:bash exe:bash[384578](parent comm:bash parent exe:[384404]) send SIGTERM 
to comm:bash exe:bash[384593].(systemd[1]) Mar 10 08:52:58 
localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: comm:bash 
exe:bash[384404](parent comm:systemd parent exe:systemd[1]) send SIGTERM to 
comm:bash exe:[384592]. Mar 10 08:52:58 localhost.localdomain sysmonitor[1191]: 
sysmonitor[1191]: comm:bash exe:bash[384578](parent comm:bash parent 
exe:[384404]) send SIGTERM to comm:bash exe:bash[384592].(systemd[1]) Mar 10 
08:52:58 localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: comm:bash 
exe:bash[384578](parent comm:bash parent exe:bash[384404]) send SIGTERM to 
comm:bash exe:[384587].(systemd[1]) Mar 10 08:52:58 localhost.localdomain 
sysmonitor[1191]: sysmonitor[1191]: comm:bash exe:bash[384404](parent 
comm:systemd parent exe:systemd[1]) send SIGTERM to comm:bash exe:bash[384587]. 
Mar 10 08:52:58 localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: 
comm:bash exe:bash[384578](parent comm:bash parent exe:bash[384404]) send 
SIGTERM to comm:bash exe:[384586].(systemd[1]) Mar 10 08:52:58 
localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: comm:bash 
exe:bash[384404](parent comm:systemd parent exe:systemd[1]) send SIGTERM to 
comm:bash exe:bash[384586]. Mar 10 08:52:58 localhost.localdomain 
sysmonitor[1191]: sysmonitor[1191]: comm:bash exe:bash[384404](parent 
comm:systemd parent exe:systemd[1]) send SIGTERM to comm:bash exe:[384584]. Mar 
10 08:52:58 localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: comm:bash 
exe:bash[384578](parent comm:bash parent exe:[384404]) send SIGTERM to 
comm:bash exe:bash[384584].(systemd[1]) Mar 10 08:52:58 localhost.localdomain 
sysmonitor[1191]: sysmonitor[1191]: comm:bash exe:bash[384578](parent comm:bash 
parent exe:bash[384404]) send SIGTERM to comm:bash exe:[384583].(systemd[1]) 
Mar 10 08:52:58 localhost.localdomain sysmonitor[1191]: sysmonitor[1191]: 
comm:bash exe:bash[384404](parent comm:systemd parent exe:systemd[1]) send 
SIGTERM to comm:bash exe:bash[384583]. Mar 10 08:52:58 localhost.localdomain 
sysmonitor[1191]: sysmonitor[1191]: comm:bash exe:bash[384578](parent comm:bash 
parent exe:bash[384404]) send SIGTERM to comm:bash 
exe:[384580].(systemd[1]) 
``` 

eval '`' reports error but $? is still 0

[Clark Wang]

See the following example (with 5.2.15):

bash-5.2$ PS1='$? >> '
0 >> eval '`'
bash: unexpected EOF while looking for matching ``'
0 >><-- press ENTER
2 >><-- now $? is 2


It looks like the failed eval '`' is still waiting for some input?

text similar to JSON can cause memory of bash to become abnormally large

[wang yuhang]

hi 
 
I accidentally copied a section of JSON text to the terminal and executed it, 
which resulted in a system crash.Bash version is 5.1.8. 
 
Later, I reproduced it and found that when I executed the following command, 
the memory usage of bash became very large. 
 
$ 
[{"key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1"},{"key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1"},{"key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1"},{"key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1","key":"1"}]
 
 
Through tracking the code, it was found that in the brace_expand_word_list 
function, there is a continuous recursive execution of the brace_expand 
function, which causes the len2 variable of function array_concat to become 
abnormally large, and then a large amount of memory will be malloced based on 
the value of len2 
 
This may be a normal manifestation of bash rather than a problem. But in the 
case of user misoperation, it can cause system crashes, so I still hope that 
this situation can be improved

 

Performance difference between different versions of bash

[wang yuhang]

Hi


I found that there is a huge difference in performance between different 
versions of bash when there are a large number of environment variables in my 
system.


The steps to reproduce are as follows??
$ for i in `seq 1`; do export TEST_ENV_$i=$i; done
$ time echo `date`


In bash-4.3, it only takes 0.002 seconds, but in bash-5.2, it takes up to 0.5 
seconds.


I want to know if this is due to certain features in the higher version of bash 
or due to some hidden bugs. 


I hope to get your help.

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Wed, Nov 8, 2017 at 9:46 PM Chet Ramey  wrote:

> On 11/7/17 11:38 PM, Clark Wang wrote:
>
> > I made a patch (also attached). Please see if it's ok.
> >
> >
> > Updated by dealing with empty strings (and malloc'ing 2 more bytes)
> > though I'm not sure if it's necessary since the func
> > sh_quote_reusable() already handles empty strings.
> >
> >
> > Hi Chet, do you have a look at my patch?
>
> I did. It's on the list of possible things for the next version. Since it's
> only a cosmetic issue, it's not a high priority.
>

Hi Chet,

Is it possible to fix this in 5.3?

git commit for 5.2 patch 16 added a "tags" file

[Clark Wang]

commit 4214b0e12b4345c970d4d50705b1443441baedf8
Author: Chet Ramey 
Date:   Fri 2023-11-10 05:39:38 +0800

Bash-5.2 patch 16: fix for a crash if one of the expressions in an
arithmetic for command expands to NULL

M   execute_cmd.c
M   patchlevel.h
A   tags

I guess it's not intentional.

bash encountered a coredump issue with stepping on memory

[wang yuhang]

Hi


A bash coredump has appeared in my environment, the stack information displayed 
by GDB is as follows:
#0  __pthread_kill_implementation (threadid=

Re?? bash encountered a coredump issue with stepping on memory

[wang yuhang]

> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.


I'm sorry, the environment is quite complex and I couldn't find a way to 
reliably reproduce it .


Currently, there is only coredump information available. If I find a 
way to reliably reproduce it, I will inform you immediately.

Re: bash encountered a coredump issue with stepping on memory

[wang yuhang]

> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.

So far, we have encountered this issue three times in our environment. The 
following is one of the coredump information 
 
#0  __pthread_kill_implementation (threadid=

Re: bash encountered a coredump issue with stepping on memory

[wang yuhang]

> The initialize_shell_variables function is processing env. When the for 
loop  
> reaches env[16], glibc needs to use the main_arena.top variable. However, 
the  
> value in the address pointed to by the top variable is overwritten by 
env[15],  
> causing a glibc exception and resulting in a coredump  
 
When the for loop reaches env, the values of each env are: 
 
(gdb) p env[0] 
$5 = 0x7ffce3c2e0bc "SHELL=/bin/bash" 
(gdb) p env[1] 
$6 = 0x7ffce3c2e0cc "REPO_PATH=/opt/pub/software" 
(gdb) p env[2] 
$7 = 0x7ffce3c2e0e8 "CURL_ALIAS=/usr/bin/curl" 
(gdb) p env[3] 
$8 = 0x7ffce3c2e101 "FIND_ALIAS=/usr/bin/find" 
(gdb) p env[4] 
$9 = 0x7ffce3c2e11a "IPMC_AGENT_ROOT=/opt/oss/manager/agent/DeployAgent" 
(gdb) p env[5] 
$10 = 0x7ffce3c2e14d "PGREP_ALIAS=/usr/bin/pgrep" 
(gdb) p env[6] 
$11 = 0x7ffce3c2e168 "FSCK_ALIAS=/usr/sbin/fsck.ext4" 
(gdb) p env[7] 
$12 = 0x7ffce3c2e187 "enableServiceIdentity=/uds" 
(gdb) p env[8] 
$13 = 0x7ffce3c2e1a2 "SUPER_ROOT=/opt/sudobin/" 
(gdb) p env[9] 
$14 = 0x7ffce3c2e1bb "HOSTNAME_ALIAS=/bin/hostname" 
(gdb) p env[10] 
$15 = 0x7ffce3c2e1d8 "SUDO_GID=2000" 
(gdb) p env[11] 
$16 = 0x7ffce3c2e1e6 "HISTCONTROL=" 
(gdb) p env[12] 
$17 = 0x7ffce3c2e1f3 "MKFIFO_ALIAS=/usr/bin/mkfifo" 
(gdb) p env[13] 
$18 = 0x7ffce3c2e210 "CHOWN_ALIAS=/bin/chown" 
(gdb) p env[14] 
$19 = 0x7ffce3c2e227 "BASH_ALIAS=/bin/bash" 
(gdb) p env[15] 
$20 = 0x7ffce3c2e23c "PROCESS_NAME=hofsosdfileagent" 
(gdb) p env[16] 
$21 = 0x7ffce3c2e25a "DIRNAME_ALIAS" 
(gdb) p env[17] 
$22 = 0x7ffce3c2e279 "PID="

Re: bash encountered a coredump issue with stepping on memory

[wang yuhang]

> Is this at the same point as the core dump in your previous message?

yes

case modification won't work with pattern

[Jerry Wang]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux Xubuntu 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11
17:36:01 UTC 2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 4.0
Patch Level: 33
Release Status: release

Description:
The case modification won't work with pattern.
I have a simple script a.sh, please see below:

#! /bin/bash
var="abcabc"
echo "var: ${var}"
echo "replace the leading \"ab\" to uppercase: ${var^ab}" # expect to 
get "ABcabc" ?
echo "replace all the \"ab\" to uppercase: ${var^^ab}"# expect to 
get "ABcABc" ?

echo "replace the first \"a\" to uppercase: ${var^a}"
echo "replace all \"a\" to uppercase: ${var^^a}"

Then the result is:

mylogin@Xubuntu:~/shell$ ./a.sh
var: abcabc
replace the leading "ab" to uppercase: abcabc   --> incorrect
replace all the "ab" to uppercase: abcabc   --> incorrect 
replace the first "a" to uppercase: Abcabc  --> correct
replace all "a" to uppercase: AbcAbc--> correct


Repeat-By:

-- 
Jerry Wang jerry.j.w...@alcatel-lucent.com 

printf treats arguments of "%c" not as expected

[Yunfeng Wang]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include
-I../bash/lib   -g -O2 -Wall
uname output: Linux loco 2.6.38-2-686 #1 SMP Tue Mar 29 17:27:45 UTC
2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
The builtin printf does not print arguments of format "%c" as described
in printf(3). /usr/bin/printf from coreutils has the same problem.

Repeat-By:

$ printf %c 65 66 67
666

The expected output is ABC, i.e. characters with ASCII code of 65 66 67

Fix:

--- bash-4.1/builtins/printf.def2009-11-21 04:31:23.0 +0800
+++ bash-4.1-new/builtins/printf.def2011-06-22 19:25:30.0 +0800
@@ -385,9 +385,9 @@
{
case 'c':
  {
-   char p;
+   int p;

-   p = getchr ();
+   p = getintmax ();
PF(start, p);
break;
  }

Re: printf treats arguments of "%c" not as expected

[Yunfeng Wang]

Hi Jonathan,

I didn't check the POSIX spec, my fault ;-)
So bash chooses to conform to POSIX regarding this behaviour, not bad I believe.
But the help message of printf is somewhat misleading as it says:

$ help printf
printf: printf [-v var] format [arguments]
Formats and prints ARGUMENTS under control of the FORMAT.
[snipped]
In addition to the standard format specifications described in printf(1)
and printf(3), printf interprets:
[snipped]

while printf(3) describes %c as below:

$ man 3 printf
[snipped]
   c  If no l modifier is present, the int argument is converted to an
  unsigned  char, and the resulting character is written.
[snipped]

That's why I thought "printf %c 65" should have printed an 'A' instead of
the initial character '6'. I also checked Perl and found what I wanted:

$ perl -e 'printf "%c\n", 65'
A

Perhaps bash should clarify this issue in its documents such that users like me
would not be misguided again.

Thanks

2011/6/23 Jonathan Nieder :
> Hi,
>
> Yunfeng Wang wrote:
>
>>     $ printf %c 65 66 67
>>     666
>>
>>     The expected output is ABC, i.e. characters with ASCII code of 65 66 67
>
> I believe the current behavior is correct.  POSIX (XCU.4.printf) sayeth[*]:
>
>        11. The argument to the 'c' conversion specifier can be a string
>            containing zero or more bytes.  If it contains one or more
>            bytes, the first byte shall be written and any additional bytes
>            shall be ignored.  If the argument is an empty string, it is
>            unspecified whether nothing is written or a null byte is written.
>
> I would suggest using something like
>
>        perl -e 'print(chr(65), chr(66), chr(67), "\n");'
>
> or
>
>        for i in 65 66 67
>        do
>                eval printf \'\\$(printf %03o "$i")\'
>        done
>        printf '\n'
>
> for your application.
>
> Back to the bug: I don't see any explanation of "printf %c" when I run
> "man bash".  Perhaps your manual is different from mine, but if you,
> perhaps it would be possible to suggest a few words to explain this
> for future readers.
>
> Thanks and regards,
> Jonathan
>
> [*] http://unix.org/2008edition/
>

Re: printf treats arguments of "%c" not as expected

[Yunfeng Wang]

Thanks Jan, Greg's solution is great!

wyf

2011/6/23 Jan Schampera :
> Hi,
>
>
> I agree this is not a bug. %c works as described.
>
> However, Mr. Wang may want to read one of Greg's brilliant FAQ entries [1].
>
> In general it's a bit of a pity that printf can do character->number
> conversion, but not (directly) back. But it is like it is and the
> "workarounds" are not really complicated.
>
>
> Jan
>
>
> [1] http://mywiki.wooledge.org/BashFAQ/071
>
> --
> Be conservative in what you do, be liberal in what you accept from others.
> - jbp, master of the net, in RFC793
>
>

Re: semicolon at beginning of line

[Clark Wang]

On Tue, Apr 10, 2012 at 16:38, Elliott Forney wrote:

> On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont 
> wrote:
> > People should stop trying to execute code by parameter expansion, and
> specifically stop thinking that parameter-expanded words are evaluated as
> bash code.
>
> I still think the behavior is interesting.  The statement may not be
> empty but nothing other than the expansion is executed.
>
> > OK, so you're saying, let's change bash so that an empty statement
> becomes a noop statement.
>
> Yes.  It already is when a newline is received.  Why not when an empty
> statement is terminated with a semicolon?
>
> >Except for when that empty statement is preceded by a semicolon and
> happens to have no whitespace, because then it could be a case delimiter.
>
> Yes.  Just like "$(" differs from "$((" and "[" from "[[" and ">" from
> ">>".  This would not be unique syntax in bash.
>
> > Frankly, what are you hoping to gain from this?
>
> I simply believe it is intuitive; this is the behavior I would expect
> before trying it.
>

+1

>
> > This will just introduce new rules with new exceptions and
> inconsistencies.  If it were possible to do a blanket rule: empty
> statements before a semicolon are noops, I might be OK with it, but if it
> requires adding additional addendums to the rule, "oh wait, except for this
> and that case", my vote is out.
>
> I really don't think it would cause lots of problems.  This belief is
> supported by the fact that this is already implemented in other
> shells.  Try the examples I have given in zsh and you will see the
> behavior I would expect.  Try it in ksh and you will see something
> closer to the blanket rule you suggest.
>
> If no one else agrees then that's cool but my vote is to change it.
>
> Thanks,
>  Elliott Forney
>
>

Re: Passing variables by reference conflicts with local

[Clark Wang]

On Wed, May 5, 2010 at 01:57, Freddy Vulto  wrote:

> It appears that `unset' is capable of traversing down the call-stack and
> unsetting variables repeatedly:
>
>a=0 b=0 c=0 d=0 e=0
>_unset() { unset -v b c c d d d e; }
>t1() {
>local a=1 b=1 c=1 d=1
>t2
>}
>t2() {
>local a=2 b=2 c=2 d=2 e=2
>_unset
>echo a:$a b:$b c:$c d:$d e:$e
>}
>t1  # Outputs: a:2 b:1 c:0 d: e:0
>#^   ^   ^   ^  ^-- unset once (skipped t1)
>#|   |   |   +- unset thrice to global
>#|   |   +- unset twice till global
>#|   +- unset once till t1
>#+- unset not
>
> It seems to work on bash-3.0, 3.2, 4.0 and 4.1.
> Is this a bug or a feature?
>

When I revisit this 2 years old thread I don't understand why following
foo() function does not output the global var:

$ cat foo.sh
var=global
foo()
{
local var=foo
unset var
echo foo: $var
}
bar_unset()
{
unset var
}
bar()
{
local var=bar
bar_unset
echo bar: $var
}
foo
bar
$ bash foo.sh
foo:
bar: global
$

In foo() it unsets its local var so why doesn't the subsequent $var refer
to the global var?

>
> Freddy Vulto
> http://fvue.nl/wiki/Bash:_passing_variables_by_reference
>
>
>

Re: Severe Bash Bug with Arrays

[Clark Wang]

On Wed, Apr 25, 2012 at 07:21, Ted Okuzumi  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: Passing variables by reference conflicts with local

[Clark Wang]

On Fri, Apr 27, 2012 at 02:02, Bill Gradwohl  wrote:

>
> So, if you want to make sure a sub
> function can't touch a variable, put another function in between that
> localises and then unsets the variable.
>

Sounds interesting. Will see if I can take advantage of this in future. :)

>
>
> --
> Bill Gradwohl
>

Re: Passing variables by reference conflicts with local

[Clark Wang]

On Fri, Apr 27, 2012 at 02:49, Greg Wooledge  wrote:

>
> I don't see this as a surprise.  It's how you return values from functions
> in bash.  Pick a global variable (r, ret, whatever you want) and stuff the
> return value into that.  You can even declare your "r" locally somewhere
> so that the value never propagates up higher than that point in the call
> chain.
>

I can understand this but I've never written code like this. Will try it
later.

>
> For example:
>
> # Return random number from 0 to ($1-1) in variable "r"
> rand() {
>  local max=$((32768 / $1 * $1));
>  while (( (r=$RANDOM) >= max )); do :; done
>  r=$((r % $1))
> }
>
> foo() {
>  local r
>  rand 42
>  ... use $r ...
> }
>
> foo
> ... we don't see "r" here because it was scoped only within foo & its kids
> ...
>
>

Re: bash build

[Clark WANG]

On Sat, Jun 2, 2012 at 7:39 AM, rac8006  wrote:
>
> What is the proper way to add popd pushd dirs etc to bash.  When I currently
> build bash these

By default those commands should be enabled. I never added special
options when buidling Bash. Not sure if it's system dependent. But
from the "configure --help" output I found this:

  --enable-directory-stackenable builtins pushd/popd/dirs

You can try if that helps. :)

> are missing.  I also get an error libintl_ngettext undefined reference.  I
> can get around this error
> by adding -lintl to the link.  Just don't know how to get the Makefile to
> add -lintl.
>
> Thanks for your help
>
> RAC
> --
> View this message in context: 
> http://old.nabble.com/bash-build-tp33947830p33947830.html
> Sent from the Gnu - Bash mailing list archive at Nabble.com.
>
>

Re: Red-Hat Bug 825751 - bash-completion fails on environment variables

[Clark WANG]

On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg  wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=825751
>
> bash-4.2.24-1.fc16.i686
>
> Steps to Reproduce:
> 1. Activate a terminal running a bash shell
> 2. ls $HOME/
> 3.
>
> Actual results:
> ls \$HOME/

Already discussed for quite a few times. :) For example:

http://lists.gnu.org/archive/html/bug-bash/2011-12/msg00079.html
(patched attached)
http://lists.gnu.org/archive/html/bug-bash/2011-12/msg00035.html


>
> I get the directory get expanded result on Bash 1.4.8 (VMS special build)
> and on Bash 3.2.25(1)-release.
>
> Regards,
> -John
>

Re: regex in bashexpression doesn't work

[Clark WANG]

On Mon, Jun 25, 2012 at 3:18 PM, Niels Carl W. Hansen <
re...@aauindy.cscaa.dk> wrote:

>
> Description:
>[[ 'foobar'  =~ 'o.a' ]] && echo FOUND
>should print  FOUND  but it doesn't.
>This have worked in previeous versions of bash.
>The bash used comes with CentOS 6.2
>

See E14 in Bash FAQ: http://tiswww.case.edu/php/chet/bash/FAQ


>
> Repeat-By:
>No privous commands necessary to generate this problem.
>
> Fix:
>
>
>

Bug with `eval return' in .bashrc ?

[Clark WANG]

For quite a long time I don't know why my bash stops remembering command
history. I just figured out it was caused by some code like `eval return'
in the .bashrc/.bash_profile.

Steps to reproduce (tested with 3.2.25, 4.0.28, 4.1.11 and 4.2.29):

$ cp .bashrc .bashrc.old
$ echo eval return > .bashrc
$ bash
$ cmd-not-found
$ history 10  <-- You'll not see cmd-not-found in the output.
$ <-- And you cannot find cmd-not-found by pressing the  arrow key.

Re: Undocumented behaviour - parameter expansion ${par-word}

[Clark WANG]

On Tue, Sep 4, 2012 at 7:13 PM, Roman Rakus  wrote:

> Hi,
> Petr, adding to cc: list, found behaviour not documented, neither in man
> page nor bash ref manual:
> ${par-word} will do expansion of par, and if the par is unset it is
> substituted by word. It is different from ${par:-word}, where word is used
> when par is unset or null.
>
> Is it undocumented and deprecated, like $[]? Or just undocumented?
>

>From man page:

   When  not  performing  substring  expansion, using the forms
documented
   below, bash tests for a parameter that is unset or null.  Omitting
the
   colon results in a test only for a parameter that is unset.


>
> RR
>
>

"break" inside a while-condition

[Philippe Wang]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin12.0.0
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='darwin12.0.0' -DCONF_MACHTYPE='i386-apple-darwin12.0.0' 
-DCONF_VENDOR='apple' -DLOCALEDIR='/alien/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I. -I./include -I./lib -I./lib/intl 
-I/Users/phil/gnuutils/bash-4.2/lib/intl  -g -O2
uname output: Darwin mba.local 12.1.0 Darwin Kernel Version 12.1.0: Tue Aug 14 
13:29:55 PDT 2012; root:xnu-2050.9.2~1/RELEASE_X86_64 x86_64
Machine Type: i386-apple-darwin12.0.0

Bash Version: 4.2
Patch Level: 0
Release Status: release

Description:
  "break" keyword inside a while-condition doesn't work as expected : it breaks 
the wrong loop.


Repeat-By:
  # 1) should raise a parsing error  (but it doesn't)
  while break ; true ; do true ; done 

  # 2) should break the outer loop  (but it doesn't)
  while true ; do while break ; do whatever-because-never-reached ; done ; echo 
fail ; done

Fix:
   I don't know.

Re: Regular expression matching fails with string RE

[Clark WANG]

On Wed, Oct 17, 2012 at 5:18 AM,  wrote:

>
> Bash Version: 4.2
> Patch Level: 37
>
> Description:
>
> bash -c 're=".*([0-9])"; if [[ "foo1" =~ ".*([0-9])" ]]; then echo
> ${BASH_REMATCH[0]}; elif [[ "bar2" =~ $re ]]; then echo ${BASH_REMATCH[0]};
> fi'
>
> This should output foo1. It instead outputs bar2, as the first match fails.
>
>
> From bash's man page:

   [[ expression ]]
  ... ...
  An additional binary operator, =~, is available, with  the
same
  ... ...
  alphabetic characters.  Any part of the pattern may be quoted
to
  force  it  to  be  matched  as  a string.  Substrings matched
by
  ... ...

Should ~$user be tilde expanded?

[Clark WANG]

See following example:

$ cat foo.sh
u=root
echo ~$u
$ bash foo.sh  # bash 4.2.37
~root
$ ksh foo.sh  # ksh 93u+ 2012-08-01
/root
$

Anyone can explain/confirm what should be the correct behavior?

-Clark

Re: RFE: printf '%(fmt)T' prints current time by default

[Clark WANG]

On Wed, Nov 14, 2012 at 7:57 PM, Roman Rakus  wrote:

> On 11/14/2012 04:00 AM, Clark WANG wrote:
>
>> In ksh:
>>
>> $ printf '%(%F %T)T\n'
>> 2012-11-14 10:57:26
>> $
>>
>> In bash:
>>
>> $ printf '%(%F %T)T\n'
>> 1970-01-01 08:00:00
>> $
>>
>> I think the ksh behavior is makes more sense so can we use the current
>> time
>> as the default?
>>
>> -Clark
>>
> For it there is -1 special parameter for printf:
>
> $ printf '%(%F %T)T\n' -1
> 2012-11-14 12:54:56
>

Thanks. As a bash user since 2.05b I did not read the man page of newer
versions carefully enough. :)

>
> RR
>
>

Re: Hitting Esc twice auto-completes

[Clark WANG]

On Wed, Nov 21, 2012 at 6:40 AM, smu johnson  wrote:

> Hi.
>
> If you are in regular emacs mode in Bash, and you hit Esc twice, it acts as
> an auto-complete, similar to just hitting tab.
>
> I cannot find this behaviour in any of the system wide bash defaults in
> /etc, or any of my own dotfiles.
>

$ bind -p | grep 'complete$'
"\C-i": complete
"\e\e": complete
$

Not sure if \e\e is on by default but if you want to disable it:

$ bind -r '\e\e'
$bind -p | grep 'complete$'
"\C-i": complete
$


>
> An op on Freenode.#bash confirmed it happened on his too, and he uses "GNU
> bash, version 4.2.39(2)-release (i686-pc-linux-gnu)".  His is far more
> recent version than mine.
>
> Thanks in advance.
>
>
> --
> smu johnson 
>

Re: Q on Bash's self-documented POSIX compliance...

[Clark WANG]

On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh  wrote:

> I noted on the bash man page that it says it will start in posix
> compliance mode when started as 'sh' (/bin/sh).
>
> What does that mean about bash extensions like arrays and
> use of [[]]?
>
> Those are currently not-POSIX (but due to both Bash and Ksh having
> them, some think that such features are part of POSIX now)...
>
> If you operate in POSIX compliance mode, what guarantee is there that
> you can take a script developed with bash, in POSIX compliance mode,
> and run it under another POSIX compliant shell?
>
> Is it such that Bash can run POSIX compliant scripts, BUT, cannot be
> (easily) used to develop such, as there is no way to tell it to
> only use POSIX?
>
> If someone runs in POSIX mode, should bash keep arbitrary bash-specific
> extensions enabled?
>
> I am wondering about the rational, but also note that some people believe
> they are running a POSIX compatible shell when they use /bin/sh, but would
> get rudely surprised is another less feature-full shell were dropped in
> as a replacement.
>

I think every POSIX compatible shell has its own extensions so there's no
guarantee that a script which works fine in shell A would still work in
shell B even if both A and B are POSIX compatible unless the script writer
only uses POSIX compatible features. Is there a pure POSIX shell without
adding any extensions?

Re: backward-line

[Clark WANG]

On Mon, Jan 28, 2013 at 3:07 PM, Egmont Koblinger  wrote:

> Hi folks,
>
> Sometimes I work with quite long command lines (4-5 lines on the screen)
> and I need to modify something somewhere in the middle.  I know a couple of
> ways to move the cursor there a little bit faster than holding the left
> arrow (e.g. backward-word, or Alt+number then left arrow), I also know
> about some non-interactive ways of editing a command line, but still I find
> all these quite frustrating and time consuming.
>
> The feature I've always missed from bash's line editing is to be able to
> move the cursor up vertically by a line, using some shortcut key.  I
> believe this makes the interactive editing of long command lines faster and
> way more convenient.
>

If I need to deal with a quite long command line I usually press C-x C-e
(or v when in vi mode) to invoke my favorite vim editor to edit the command
and then run it. With vim, you can press gj and gk for your purpose here.
(Actually I always nnoremap j to gj and k to gk in my vimrc. :)

>
> I've quickly prototyped such a feature.  Please apply the attached patch,
> put this in your .inputrc:
>   "\e[1;5A": backward-line
>   "\e[1;5B": forward-line
> and try Ctrl+Up and Ctrl+Down on multi-line command lines to move the
> cursor vertically.
>
> Do you guys like this feature, do you think it could make it into official
> bash?
>
> If so, let me come up with a proper patch (it's going to be much more
> complicated in order to support double wide characters.  The current one is
> just a quick demo of the proposed feature which only works correctly with
> single-cell characters.)
>
>
> thx,
> egmont
>

Re: flag for quiet CDPATH

[Clark WANG]

On Tue, Jan 21, 2014 at 8:16 AM, Elliott Forney wrote:

> I find it a little unpleasant that cd echoes the new working directory
> when CDPATH is used to locate the new directory (I already have the
> working directory in my prompt).  I understand that this is behavior
> is mandated by POSIX but I wonder if we could have an option that
> disables this.
>

+1 and `cd -' has the similar problem.

>
> Maybe if the `cd' builtin had an option, say `-q', that would cause it
> to be quit if CDPATH is used.  Then, I could simply
>
> alias cd='cd -q'
>
> and put a stop to this.  I have attached a proposed patch, any thoughts?
>
> Thanks,
> ---
> Elliott ForneyE-Mail: id...@cs.colostate.edu
> Graduate Student  Phone:  1.402.215.7440
> Computer Science Department   Web:
> http://www.cs.colostate.edu/~idfah
> Colorado State University
>

direxpand in 4.3 is different from in 4.2

[Clark Wang]

For example in 4.3 when direxpand is enabled, `cd ./tmp' would be
expand `./tmp' to the full path (e.g. `/root/tmp/'). I think this is not
good especially when the full dir path is very long. Bash 4.2 (tested with
4.2.37) does not behave like this. Could we keep the 4.2 behavior?

-clark

Re: direxpand in 4.3 is different from in 4.2

[Clark Wang]

On Sat, Mar 15, 2014 at 12:06 AM, Chet Ramey  wrote:

> On 3/14/14 2:39 AM, Clark Wang wrote:
> > For example in 4.3 when direxpand is enabled, `cd ./tmp' would be
> > expand `./tmp' to the full path (e.g. `/root/tmp/'). I think this is not
> > good especially when the full dir path is very long. Bash 4.2 (tested
> with
> > 4.2.37) does not behave like this. Could we keep the 4.2 behavior?
>
> This isn't accurate.  When you build bash-4.3 with the default options, and
> choose to enable direxpand using shopt, you get the same behavior as in
> bash-4.2.  In particular, relative paths aren't expanded to full paths.
>
> Recompiled with default options and it worked fine. Thanks.


> If, on the other hand, you build bash with the enable-direxpand-default
> configuration option, you do get this behavior.  I left the relative-path
> expansion option enabled when bash is built this way.  In retrospect, I
> should probably have left it out.  If you prefer it disabled, you can
> change the assignment to dircomplete_expand_relpath in bashline.c.
>
> That is not to say there aren't problems with relative paths and completion
> in bash-4.3, but they aren't with direxpand.  Additionally, I'm not talking
> about the situation when bash-completion is included in the mix.
>
> Chet
> --
> ``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/
>

Another direxpand problem in 4.3?

[Clark Wang]

See following example with bash-4.3.11 (compiled with the default configure
option):

[STEP 101] $ complete -r
[STEP 102] $ shopt direxpand
direxpand   on
[STEP 103] $ find .
.
./the-dir
./the-dir/file
./the dir
./the dir/file
[STEP 104] $ foo the-
[STEP 104] $ foo the-dir/
[STEP 104] $ foo the-dir/file
bash: foo: command not found
[STEP 105] $ foo the\
[STEP 105] $ foo the\ dir/
[STEP 105] $ foo /root/tmp/direxpand/the\ dir/file
bash: foo: command not found
[STEP 106] $

In STEP 105 the relative path was expanded to the full path. I think it
should not.

-clark

`complete -d cd' does not work for dirs with a ' char

[Clark Wang]

See following example with bash-4.3.11:

[STEP 101] $ mkdir -p "foo's dir/dir1/dir2"
[STEP 102] $ complete -d cd
[STEP 103] $ cd 
[STEP 103] $ cd foo\'s\ dir/

The 1st  worked fine but the 2nd failed to work. Bash 4.2.47 and 4.1.9
behaved the same.

-clark

Re: `complete -d cd' does not work for dirs with a ' char

[Clark Wang]

On Sat, Apr 26, 2014 at 3:41 AM, Chet Ramey  wrote:

> On 4/23/14, 11:21 PM, Clark Wang wrote:
> > See following example with bash-4.3.11:
> >
> > [STEP 101] $ mkdir -p "foo's dir/dir1/dir2"
> > [STEP 102] $ complete -d cd
> > [STEP 103] $ cd 
> > [STEP 103] $ cd foo\'s\ dir/
> >
> > The 1st  worked fine but the 2nd failed to work. Bash 4.2.47 and
> 4.1.9
> > behaved the same.
>
> Thanks for the report.  The problem is that in this case, the directory
> name is dequoted twice.  In most cases, it doesn't matter, but it will
> fail if the directory name has a backslash-quoted quote, as in your
> example.
>
> The attached patch will fix it.
>

The patch works fine. Thanks.

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

RFE: remove duplicate entries from the result of `compgen -W'

[Clark Wang]

See following example:

  $ echo $BASH_VERSION
  4.3.18(1)-release
  $ compgen -W 'hello hello' h
  hello
  hello
  $

It'll be good if only one "hello" is outputted.

-clark

Re: RFE: remove duplicate entries from the result of `compgen -W'

[Clark Wang]

On Mon, Sep 8, 2014 at 1:07 AM, Chet Ramey  wrote:

> On 9/4/14, 10:33 PM, Clark Wang wrote:
> > See following example:
> >
> >   $ echo $BASH_VERSION
> >   4.3.18(1)-release
> >   $ compgen -W 'hello hello' h
> >   hello
> >   hello
> >   $
> >
> > It'll be good if only one "hello" is outputted.
>
> `complete' and `compgen' only generate lists of possible completions.
> Readline performs duplicate removal when it is deciding what to do
> with that list.
>

Thanks, Chet. I did not realized this.

In the following example I'll describe my use case and you can understand
why my requirement.

Many commands like ping and ssh would take a hostname as their parameter.
I'm trying to define a common compspec for all these commands since
bash-4.1 added the `complete -D' option which is very cool. My idea is just
like bash's builtin completion behavior when we input `@' but I'd like
the `@' char to be automatically removed when there's only one host
matching. See following demo code:

  function compgen_hosts
  {
  local cmd=$1
  local cur=$2
  local pre=$3
  local -a hosts
  local host

  hosts=( $(awk '$1 !~ /^ *#/' /etc/hosts) )

  if [[ $cur == @* ]]; then
  host=${cur#*@}
  COMPREPLY=( $( compgen -P @ -W "${hosts[*]}" "$host") )
  fi

  if [[ ${#COMPREPLY[@]} == 1 ]]; then
  COMPREPLY[0]=${COMPREPLY[0]#@}
  fi
  }

  complete -D -o nospace -F compgen_hosts

For most of the time this works fine. For example:

  $ foo @host-
  @host-a.us  @host-b.us
  $ foo @host-a
  $ foo host-a.us

But there's a small problem because there are duplicate hostnames. For
example both `127.0.0.1` and `::1` are mapping to `localhost' and then my
code would not work:

  $ foo @localhost
  @localhost
  $

The reason is the `if [[ ${#COMPREPLY[@]} == 1 ]]' condition. For
`localhost' there are two candidates in COMPREPLY:

  COMPREPLY=( localhost localhost )

I know I can manually remove duplicate entries (either when reading
/etc/hosts or from the output of compgen) but it would be convenient if the
result of compgen has already done that for me. :)

Thanks.

-clark

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

PIPESTATUS inconsistent behavior in 3.0

[Frank Wang]

Configuration Information [Automatically generated, do
not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash'
-DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu
' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/sh
are/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H 
-I.  -I. -I./include -I./lib  -
D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wp,-D_FORTIFY_S
OURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables
uname output: Linux twinhead.yafrank.homeip.net
2.6.12.3-min3 #1 Sat Aug 6 21:13:43 C
ST 2005 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
Here is what I got from my fc4 box.
[EMAIL PROTECTED] ~]$ echo $BASH_VERSION
3.00.16(1)-release
[EMAIL PROTECTED] ~]$ ls | bogus_command | wc
  0   0   0
[EMAIL PROTECTED] ~]$ echo [EMAIL PROTECTED]
141 127 0
[EMAIL PROTECTED] ~]$ ls | tr [:lower:] [:upper:] |
bogus_command | wc
bash: bogus_command: command not found
  0   0   0
[EMAIL PROTECTED] ~]$ echo [EMAIL PROTECTED]
0 141 127 0
[EMAIL PROTECTED] ~]$ ls | bogus_command |
bogus_command2 | wc
bash: bogus_command: command not found
bash: bogus_command2: command not found
  0   0   0
[EMAIL PROTECTED] ~]$ echo [EMAIL PROTECTED]   # seems
right here
0 127 127 0

However, in 9.1. Internal Variables, Advanced
Bash-Scripting Guide 3.5 by Men
del Cooper
(http://www.tldp.org/LDP/abs/html/abs-guide.html)
...
bash$ echo $BASH_VERSION
3.00.0(1)-release
bash$  ls | bogus_command | wc
bash: bogus_command: command not found
 0   0   0
bash$ echo [EMAIL PROTECTED]
0 127 0
I don't have bash-3.00.0(1) in my box to test.
If abs is right, then there is
 inconsistency between the two patched version.


Repeat-By:
 Run same pipe concatenated command with bogus
command inserted in bash-3.00.
0(1) and bash-3.00.16(1) then capture the PIPESTATUS
immediately after will report di
fferent return code.


Send instant messages to your online friends http://uk.messenger.yahoo.com 


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

"test -w aquota.user" gives different exit code after quotaon run

[Frank Wang]

Configuration Information [Automatically generated, do
not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash'
-DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='i386-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 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386
-mtune=pentium4 -fasynchronous-unwind-tables
uname output: Linux twinhead.yafrank.homeip.net
2.6.12.3-min3 #1 Sat Aug 6 21:13:43 CST 2005 i686 i686
i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
A user quota management script recently always aborts
in a fc3 server with latest update. Experiment shows
that '[ -w /usr/local/aquota.user ]' returns 1 after
quotaon run triggers the abortion. The same script
used to work fine in early fc3. Enable quota in my fc4
box's /usr/local partition and do following test shows
similar behavior:

[EMAIL PROTECTED] local]# pwd
/usr/local
[EMAIL PROTECTED] local]# quotaoff -aup
user quota on /usr/local (/dev/hda9) is off
[EMAIL PROTECTED] local]# ls -l aquota*
-rw---  1 root root 11264  8月 18 18:36
aquota.user
[EMAIL PROTECTED] local]# [ -r aquota.user ] && echo true
true
[EMAIL PROTECTED] local]# [ -w aquota.user ] && echo true
true
[EMAIL PROTECTED] local]# quotaon -au
[EMAIL PROTECTED] local]# quotaon -aup
user quota on /usr/local (/dev/hda9) is on
[EMAIL PROTECTED] local]# ls -l aquota*
-rw---  1 root root 11264  8月 18 18:36
aquota.user
[EMAIL PROTECTED] local]# [ -w aquota.user ] && echo true
[EMAIL PROTECTED] local]# [ -r aquota.user ] && echo true
true

Why "test -w aquota.user" returns different exit code
after quotaon run while ls shows the same permission?
Do I make anything wrong here?

Repeat-By:
Turn on and off quota and compare exit code from
"test -w /path/to/mount_point/aquota.user"

Send instant messages to your online friends http://uk.messenger.yahoo.com 


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

`set completion-ignore-case on' does not work well for the first word on command line

[Jian Wang]

When using Bash, I often turn on the `completion-ignore-case' option of
readline. It works fine for most cases but sometimes it does not work as
expected when completing the first word on the command line. For example,
there is a bash script ~/MyDir/Foo.sh, on command line, when I input ~/my
and then press TAB, the word is completed as ~/myDir . Is that a bug?

Re: `set completion-ignore-case on' does not work well for the first word on command line

[Jian Wang]

On Feb 17, 2008 5:21 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:

> Jian Wang wrote:
> > When using Bash, I often turn on the `completion-ignore-case' option of
> > readline. It works fine for most cases but sometimes it does not work as
> > expected when completing the first word on the command line. For
> example,
> > there is a bash script ~/MyDir/Foo.sh, on command line, when I input
> ~/my
> > and then press TAB, the word is completed as ~/myDir . Is that a bug?
>
> It's not really a bug, since case-ignoring does not necessarily mean
> case-changing (this is usually called `case-preserving').  Readline uses
> what's found in the file system rather than preserving what the user
> typed, though, as you noticed when you tried to do word completion instead
> of command completion.  It might be useful to emulate Readline's behavior
> while doing command word completion.
>
Thanks for your reply but I'm a bit confused. You said that readline uses
what's found in the file system rather than preserving what the user typed.
But for my example, ~/MyDir should be found in the file system but why it's
completed as ~/myDir? Readline behaves differently between word completion
and command completion? Or, command completion is done by Bash itself other
than readline? And I noticed that if I first input /home/myname/my and than
press TAB, it'll be correctly completed as /home/myname/MyDir . What's the
difference?

>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>   Live Strong.  No day but today.
> Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
> http://cnswww.cns.cwru.edu/~chet/ <http://cnswww.cns.cwru.edu/%7Echet/>
>
>

Re: `set completion-ignore-case on' does not work well for the first word on command line

[Jian Wang]

On Feb 18, 2008 3:59 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:

> Jian Wang wrote:
> > On Feb 17, 2008 5:21 AM, Chet Ramey <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Jian Wang wrote:
> >  > When using Bash, I often turn on the `completion-ignore-case'
> > option of
> >  > readline. It works fine for most cases but sometimes it does not
> > work as
> >  > expected when completing the first word on the command line. For
> > example,
> >  > there is a bash script ~/MyDir/Foo.sh, on command line, when I
> > input ~/my
> >  > and then press TAB, the word is completed as ~/myDir . Is that a
> bug?
> >
> > It's not really a bug, since case-ignoring does not necessarily mean
> > case-changing (this is usually called `case-preserving').  Readline
> uses
> > what's found in the file system rather than preserving what the user
> > typed, though, as you noticed when you tried to do word completion
> > instead
> > of command completion.  It might be useful to emulate Readline's
> > behavior
> > while doing command word completion.
> >
> > Thanks for your reply but I'm a bit confused. You said that readline
> > uses what's found in the file system rather than preserving what the
> > user typed. But for my example, ~/MyDir should be found in the file
> > system but why it's completed as ~/myDir? Readline behaves differently
> > between word completion and command completion?  Or, command completion
> > is done by Bash itself other than readline?
>
> Readline does a fine job of completing filenames in the current
> directory, or completing a full pathname.  Since command completion
> is inherently application-specific and doesn't match well with that
> limited set of capabilities, bash does it internally, only resorting
> to readline in a couple of cases.  The way bash does things results
> in this one specific instance differing from readline's filename
> completion.
>
Thank you so much.

>
> > And I noticed that if I
> > first input /home/myname/my and than press TAB, it'll be correctly
> > completed as /home/myname/MyDir . What's the difference?
>
> The tilde prefix, which needs to be expanded so pathnames can be checked
> for the correct attributes (e.g., executability) and then removed.  If
> you look at the code, you'll see that bash appends the remainder of a
> completed pathname to what the user typed, which includes the tilde
> prefix, since the rest of the code has to expand the tilde prefix before
> doing the checking it needs to.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>   Live Strong.  No day but today.
> Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
> http://cnswww.cns.cwru.edu/~chet/ <http://cnswww.cns.cwru.edu/%7Echet/>
>
>

Eval ${#name[subscript]} incorrect when having multibyte characters.

[Wang Xin]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./incl
ude -I./lib   -g -O2
uname output: Linux shan 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38 CDT 2008 i686 I
ntel(R) Celeron(R) M processor 1.40GHz GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
When there are multibyte characters in an element of array, the
result of ${#name[subscript]} will be incorrect. It will be evaled
to numbers of bytes, but not numbers of characters.

Repeat-By:
This can be reproduced by:
1. a[0]=你好
2. echo ${#a[0]}

There are only two chinese characters, but the result is 6.

Fix:
Following patch may be helpful.

--- subst.c 2008-07-06 15:47:14.0 +0800
+++ bash-3.2/subst.c2008-07-06 15:47:39.0 +0800
@@ -4763,7 +4763,7 @@
   else
 t = (ind == 0) ? value_cell (var) : (char *)NULL;

-  len = STRLEN (t);
+  len = MB_STRLEN (t);
   return (len);
 }
 #endif /* ARRAY_VARS */

Eval ${#name[subscript]} incorrect when having multibyte characters.

[Wang Xin]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./incl
ude -I./lib   -g -O2
uname output: Linux shan 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38 CDT 2008 i686 I
ntel(R) Celeron(R) M processor 1.40GHz GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
When there are multibyte characters in an element of array, the
result of ${#name[subscript]} will be incorrect. It will be evaled
to numbers of bytes, but not numbers of characters.

Repeat-By:
This can be reproduced by:
1. a[0]=你好
2. echo ${#a[0]}

There are only two chinese characters, but the result is 6.

Fix:
Following patch may be helpful.

--- subst.c2008-07-06 15:47:14.0 +0800
+++ bash-3.2/subst.c2008-07-06 15:47:39.0 +0800
@@ -4763,7 +4763,7 @@
   else
 t = (ind == 0) ? value_cell (var) : (char *)NULL;

-  len = STRLEN (t);
+  len = MB_STRLEN (t);
   return (len);
 }
 #endif /* ARRAY_VARS */

Re: [bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed

[Jian Wang]

On Fri, Oct 31, 2008 at 14:59, Chris F.A. Johnson <[EMAIL PROTECTED]>wrote:

> On 2008-10-31, Clark J. Wang wrote:
> ...
> > # read line <&11<--- test with fd 11
> > bash: 11: Bad file descriptor
> > #
>
> You haven't opened file descriptor 11:
>
You're right. I just want to show the different behavior of fd 10 and 11. Fd
10 is closed but afterward read from it reported no error. That's the
problem.

>
> $ (
> exec 11<$HOME/.bashrc
>
> while read <&11
> do
>  printf .
> done
> echo
>
> exec 11<&-
> )
> 
>
>
> --
>   Chris F.A. Johnson, webmaster <http://Woodbine-Gerrard.com>
>   ===
>   Author:
>   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
>

Re: [bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed

[Jian Wang]

On Fri, Oct 31, 2008 at 14:18, Clark J. Wang <[EMAIL PROTECTED]> wrote:

> Hi, all:
>
> When I was doing some testing I found the file descriptor 10 is always
> duplicate of fd 0 and it cannot be closed.
>
> See the following commands:
>
> # echo $BASH_VERSION
> 3.2.39(1)-release
> # read line <&10
> hello<--- input from keyboard
> # echo $line
> hello
> # exec 10<&-<--- try to close fd 10
> # read line <&10<--- no error reported, so fd 10 is still open?
> hello<--- input from keyboard
> # echo $line
> hello
> # read line <&11<--- test with fd 11
> bash: 11: Bad file descriptor
> #
>
And, even though we can read from fd 10 but there's no such an fd under
/proc/$$/fd directory.

bash associative array not working at all, so stupid!

[Wang Xuancong]

man page: minor problem regarding ${parameter@operator}

[Clark Wang]

See:

   ${parameter@operator}
  Parameter transformation.  The expansion is either a
transforma-
  tion of the value of parameter or  information  about
parameter
  itself,  depending on the value of operator.  Each operator
is a
  single letter:
  [...]
  If parameter is @ or *, the operation is applied to  each
posi-
  tional  parameter  in  turn,  and the expansion is the
resultant
  list.  If parameter is an array variable subscripted with  @
or
  *,  the case modification operation is applied to each member
of
  the array in turn, and the expansion is the resultant list.

In the last sentence, "the case modification operation" should be "the
operation".

Re: Documentation issue

[Clark Wang]

On Fri, Oct 27, 2017 at 3:00 AM, Eli Barzilay  wrote:

> On Thu, Oct 26, 2017 at 2:02 PM, Chet Ramey  wrote:
> >
> > It's more of a general statement about arrays, though it appears in
> > the paragraph that discusses unset, so it's in the man page section on
> > arrays.  You have to be careful about putting the same information in
> > too many different places -- the man page is big enough already.
>
> I'm very aware of man page bloat and the fact that the bash page is very
> long as is.  But (a) I think that the builtin section for each command
> is the more important place for such things; and (b) what I'm suggesting
> is just a short reminder sentence about the need for quoting unsets for
> array elements.
>
> To make it more concrete, I think that the following change will be
> good:
>
> 1. Drop the current "Care must be taken ... the entire array." two
>sentences and replace them with some "See the unset builtin
>description below".
>

It's not only about unset. You also need to take care of other builtin
commands:

cd: cd a[dir] vs. cd 'a[dir]'
echo: echo foo[bar] vs. echo 'foo[bar]'; echo * vs. echo '*'
eval: eval a[i]=b vs. eval 'a[i]=b'
printf: printf foo[bar] vs. printf 'foo[bar]'
set: set a[b] vs. set 'a[b]'
source: source file[name] vs. source 'file[name]'
test: test a[b] vs. test 'a[b]'
...

and even for external commands:

find /the/dir -name *.txt

Re: Documentation issue

[Clark Wang]

On Fri, Oct 27, 2017 at 1:17 PM, Eli Barzilay  wrote:

>
> I already said why `unset` is different.  If it wasn't clear, a direct
> example is the fact that `delete` in javascript is a special syntax
> rather than a function.  To make it more confusing, the other obvious
> place where an lvalue appears (left of a =), is special in bash for
> other reasons, but it does make it easier to assume that `unset` is
> special.
>

What `unset' does is special but there's nothing special when parsing the
command and bash even does not care if it's built-in command or not.

remove empty '' in ${var@Q} result?

[Clark Wang]

See following example:

[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=\'\'
[STEP 102] # printf '%q\n' "$v"
\'\'
[STEP 103] # printf '%s\n' "${v@Q}"
''\'''\'''
[STEP 104] #

Re: Documentation issue

[Clark Wang]

On Fri, Oct 27, 2017 at 3:28 PM, Eli Barzilay  wrote:

> On Fri, Oct 27, 2017 at 2:37 AM, Clark Wang  wrote:
> >
> > What `unset' does is special but there's nothing special when parsing
> > the command and bash even does not care if it's built-in command or
> > not.
>
> Exactly -- and this kind of a clarification is exactly the thing that
> many people are unaware of.
>
> (And in case it wasn't clear: I said that unset is different in the
> expectations that people have with it, not in how it expands.)
>

Different people have different expectations which they believe are all
important. It's not possible to cover so many tricky things in the manual.
To me the most important thing is to describe the syntax correctly. When
you understand the syntax "unset arr[i]" would never surprise you.

${var@Q}: don't quote unless necessary?

[Clark Wang]

See following example:

[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=abc
[STEP 102] # printf '%q\n' $v
abc
[STEP 103] # printf '%s\n' "${v@Q}"
'abc'
[STEP 104] #

Is it possible to not quote the result since there's no special chars in
the string? I would expect ${var@Q} to produce more concise result compared
to `printf %q' since it's the new syntax. :)

-clark

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey  wrote:

>
> This is an effect of using single quotes in the @Q operator. If you want
> to single-quote a string containing single quotes, this is how you do it.
>

I made a patch (also attached). Please see if it's ok.

Tested with arr=('' a \' \'\' \'\'\' \'a a\' \'a\'a). the result will be:

arr[0]=''
arr[1]='a'
arr[2]=\'
arr[3]=\'\'
arr[4]=\'\'\'
arr[5]=\''a'
arr[6]='a'\'
arr[7]=\''a'\''a'

--- a/lib/sh/shquote.c
+++ b/lib/sh/shquote.c
@@ -98,34 +98,32 @@ sh_single_quote (string)
   register int c;
   char *result, *r;
   const char *s;
+  int left_quote_inserted = 0;

-  result = (char *)xmalloc (3 + (4 * strlen (string)));
+  result = (char *)xmalloc (1 + (3 * strlen (string)));
   r = result;

-  if (string[0] == '\'' && string[1] == 0)
-{
-  *r++ = '\\';
-  *r++ = '\'';
-  *r++ = 0;
-  return result;
-}
-
-  *r++ = '\'';
-
   for (s = string; s && (c = *s); s++)
 {
-  *r++ = c;
-
-  if (c == '\'')
-   {
- *r++ = '\\';  /* insert escaped single quote */
+  if (c == '\'') {
+   if (left_quote_inserted) {
+ *r++ = '\'';
+ left_quote_inserted = 0;
+   }
+   *r++ = '\\';
+   *r++ = '\'';
+  } else {
+   if ( ! left_quote_inserted) {
  *r++ = '\'';
- *r++ = '\'';  /* start new quoted string */
+ left_quote_inserted = 1;
}
+   *r++ = c;
+  }
 }
-
-  *r++ = '\'';
-  *r = '\0';
+  if (left_quote_inserted) {
+*r++ = '\'';
+  }
+  *r++ = 0;

   return (result);
 }


sh_single_quote.patch
Description: Binary data

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang  wrote:

> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey  wrote:
>
>>
>> This is an effect of using single quotes in the @Q operator. If you want
>> to single-quote a string containing single quotes, this is how you do it.
>>
>
> I made a patch (also attached). Please see if it's ok.
>

Updated by dealing with empty strings (and malloc'ing 2 more bytes) though
I'm not sure if it's necessary since the func sh_quote_reusable() already
handles empty strings.


sh_single_quote.patch
Description: Binary data

Claim `declare' as a special command in manual?

[Clark Wang]

For now the `declare' command is under SHELL BUILTIN COMMANDS in the man
page so people may think bash parses the command line parameters the same
way as other built-in commands which is not true.

  [STEP 100] # echo $BASH_VERSION
  4.4.12(4)-release
  [STEP 101] # declare -a arr=()
  [STEP 102] # echo declare -a arr=()
  bash: syntax error near unexpected token `('
  [STEP 103] #

It seems to me bash internally parses the `declare' command specially and
(logically) convert `declare -a arr=()' to two statements `declare -a arr'
and `arr=()'.

So does it make sense to move `declare' out of the SHELL BUILTIN COMMANDS
and put it in a separate section? Or at least explicitly state that
`declare' is special?

-clark

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Mon, Oct 30, 2017 at 8:35 PM, Greg Wooledge  wrote:

>
> What's the bug?  They are equivalent.
>

It's not a bad thing if we can make the language a bit more elegant unless
the cost is not worth it.

>
> If you mean "I would like bash to perform a second optimization pass
> over the result of ${var@Q} so that it's prettier in my degenerate edge
> cases", I suspect there are better uses of Chet's time, but it's his call.
>

It's not necessarily to perform a second pass parsing.

-clark

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Tue, Oct 31, 2017 at 3:53 PM, Clark Wang  wrote:

> On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang  wrote:
>
>> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey  wrote:
>>
>>>
>>> This is an effect of using single quotes in the @Q operator. If you want
>>> to single-quote a string containing single quotes, this is how you do it.
>>>
>>
>> I made a patch (also attached). Please see if it's ok.
>>
>
> Updated by dealing with empty strings (and malloc'ing 2 more bytes) though
> I'm not sure if it's necessary since the func sh_quote_reusable() already
> handles empty strings.
>

Hi Chet, do you have a look at my patch?

Problem after removing keybinding for bind -m vi-insert '"jj": "\e\e"'

[Clark Wang]

[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # bind -m vi-insert '"jj": "\e\e"'
[STEP 102] # bind -X
"jj": "\e\e"
[STEP 103] # bind -r jj
[STEP 104] # bind -X
[STEP 105] # <-- Here when I press j it still waits for about 1 second
to show up.

set $'\001'; v=$* converted $'\001' to $'\001\001'

[Clark Wang]

See following example:

[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # set -- $'\001'
[STEP 102] # v=$*
[STEP 103] # printf '%q\n' "$v"
$'\001\001'
[STEP 104] #

Re: set $'\001'; v=$* converted $'\001' to $'\001\001'

[Clark Wang]

On Mon, Jan 15, 2018 at 11:44 PM, Chet Ramey  wrote:

> On 1/15/18 1:26 AM, Clark Wang wrote:
> > See following example:
> >
> > [STEP 100] # echo $BASH_VERSION
> > 4.4.12(4)-release
> > [STEP 101] # set -- $'\001'
> > [STEP 102] # v=$*
> > [STEP 103] # printf '%q\n' "$v"
> > $'\001\001'
> > [STEP 104] #
>
> Thanks for the report. This was fixed last month after a report from back
> in November. The fix is in the devel branch.
>

Hi Chet, what kind of bug fixes can we expect to be backported to the
current release branch (4.4)?

-clark

Re: Feature request: PROMPT_COMMANDS array variable

[Clark Wang]

On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione 
wrote:

> Right now, PROMPT_COMMAND gives a shell command to run before displaying
> the prompt. It's common these days to include in one's bash configuration
> numerous packages from different sources that *all* want to run code at
> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
> stores a list of shell commands to execute? With a PROMPT_COMMANDS
> variable, different packages can independently add their hooks without
> stepping on each other.
>

I would define my own array var and go through it in PROMPT_COMMAND. (My
PROMPT_COMMAND is just a function name.)

Re: Quoting and string comparison

[Clark Wang]

On Thu, Feb 8, 2018 at 9:05 PM, Jaan Vajakas  wrote:

> Hi!
>
> I noticed a weird behavior. Is it a bug?
>
> Namely, why does
>
> echo "$(for f in a b c; do if [[ \"$f\" > b ]]; then echo "$f > b"; else
> echo "$f <= b"; fi; done)"
>

Should be:

  echo "$(for f in a b c; do if [[ $f > b ]]; then echo "$f > b"; else echo
"$f <= b"; fi; done)"


> output
>
> a <= b
> b > b
> c > b
>
> ?
>
> I would have expected the same output as one of
> echo "$(for f in a b c; do if [[ "$f" > b ]]; then echo "$f > b"; else echo
> "$f <= b"; fi; done)"
> echo "$(for f in a b c; do if [[ '"$f"' > b ]]; then echo "$f > b"; else
> echo "$f <= b"; fi; done)"
>
> This happens e.g. on GNU Bash v4.4 (e.g.
> https://www.tutorialspoint.com/execute_bash_online.php ).
>
>
> Best regards,
> Jaan
>

Re: Unset array doesn't work

[Clark Wang]

On Mon, Feb 12, 2018 at 2:45 PM, Nikolai Kondrashov 
wrote:

> On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
>
>>  inner() {
>>  unset res
>>
>
> Oh, and duplicating this line fixes the issue.
>

Take a look at these links:

 - http://wiki.bash-hackers.org/commands/builtin/unset
 - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference

Re: Unset array doesn't work

[Clark Wang]

On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov 
wrote:

>
>> Take a look at these links:
>>
>>   - http://wiki.bash-hackers.org/commands/builtin/unset
>>   - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference
>>
>
> Thanks, Clark! However, I find it difficult to follow the explanation at
> the
> first link and even more difficult to connect it to this case. So I'm not
> sure
> I'm getting it right. Could you maybe explain what exactly happens in the
> code
> I posted?
>

Your code:

inner() {
unset res
if [[ $1 == "set" ]]; then
res[0]="X"
res[1]="Y"
fi
}

outer() {
local res=
inner "$1"
echo "res: ${res[@]}"
}

The "unset" in inner() actually unsets the "res" in outer() and the
following assignment (to res[0] and res[1]) is actually assigning to the
global var "res". And in outer(), after calling inner(), its local "res" is
gone and it also referencing to the global var "res".

With 2 "unset" commands, even the global "res" is unset.

Re: misleading error message from variable modifier

[Clark Wang]

On Sat, Feb 24, 2018 at 11:20 AM, don fong  wrote:

>
> i would like to submit this change for inclusion in bash.  how should i
> proceed?
>

It's very common to send patches directly to this mailing list. I believe
it's also OK to send only to Chet. :)

Re: Unset array doesn't work

[Clark Wang]

On Mon, Feb 26, 2018 at 11:07 PM, Greg Wooledge  wrote:

> On Mon, Feb 26, 2018 at 09:57:10AM -0500, Clint Hepner wrote:
> > If necessary, you can define a global (at the expense of a single
> subprocess)
> >
> > myIFS=$(printf ' \t\n')
>
> That actually won't work, because $(...) strips the trailing newline(s).
> This might work:
>
> myIFS=$(printf ' \t\nx') myIFS=${myIFS%x}
>

What about myIFS=$(printf ' \n\t')? Does the order of chars in IFS make a
difference?

Re: misleading error message from variable modifier

[Clark Wang]

On Fri, Mar 2, 2018 at 12:37 PM, don fong  wrote:

> Chet, thanks.  in subst.c there is code that looks similar to what i had
> suggested.  but i don't see the tests that i submitted.  i also don't see
> the change listed in CHANGES?
>

It's in the file CWRU/CWRU.chlog:

   2/24
   
subst.c
- parameter_brace_expand_error: add parameter saying whether or not
  we are checking whether value is null, so we can have different
  error messages for ${x:?} and ${x?}. Report and fix from
  don fong 

Re: coding standards

[Clark Wang]

On Sun, Mar 4, 2018 at 5:15 AM, don fong  wrote:

> admittedly this is a very minor point, but i am curious.  this has to do
> with coding standards for bash source.
>
> consider an if statement in C (or bash, for that matter).  which is form is
> better?
>
> Form (A):
>
> if (flag)
> X();
> else
> Y();
>
> Form (B):
>
> if (flag == 0)
> Y();
> else
> X();
>
> they are functionally equivalent.  but IMHO (A) is slightly more readable.
> first because flag (in this case) is intended to be a boolean value not
> arithmetic, and second because it's simpler to think about an if when the
> condition is positive.
>
> this is what i'd say if (B) were under code review.
>
> i submitted a patch with code in form (A).  it was added to the code base
> in form (B).  was there a good reason for this mutation?
>

I believe the main reason is to keep consistent with existing code.

I used to use ``if (flag)'' but these days I'd prefer ``if (flag != /* or
== */ 0)'' which is  explicit that ``flag'' is not a boolean var. I use
``if (flag)'' only when `flag' is a boolean. It's similar I used to write
``if (ptr)'' but now I prefer ``if (ptr != NULL)'' which is explicit that
`ptr' is a pointer.

Re: coding standards

[Clark Wang]

On Mon, Mar 5, 2018 at 9:13 AM, don fong  wrote:

> Clark, thanks for your answer.
>
> I use ``if (flag)'' only when `flag' is a boolean.
>
>
> but in this case, it *is* a boolean, as i stated, and as can be seen in
> subst.c:
>
> +{
> +  if (check_nullness)
> +  report_error (_("%s: parameter null or not set"), name);
> +  else
> +  report_error (_("%s: parameter is not set"), name);
> +}
>

Just took a look at the code and it is an int:

@@ -6849,8 +6849,9 @@ parameter_brace_expand_rhs (name, value, c, quoted,
pflags, qdollaratp, hasdolla
used as the error message to print, otherwise a standard message is
printed. */
 static void
-parameter_brace_expand_error (name, value)
+parameter_brace_expand_error (name, value, check_nullness)
  char *name, *value;
+ int check_nullness;
 {
   WORD_LIST *l;
   char *temp;

Re: coding standards

[Clark Wang]

I don't know much about bash's source code so I cannot comment much. And
this kind of arguments are quite opinion based which are not simple yes/no
questions. And I believe one thing - the world is not perfect. :)

-clark

On Tue, Mar 6, 2018 at 8:26 AM, don fong  wrote:

> Clark,
>
> Just took a look at the code and it is an int:
>
>
> declaring boolean quantities as int is a common practice in old C code.
> indeed, all the boolean vars in this program seem to be declared as int.
> at least, i don't see anything declared as bool.
>
> declared type notwithstanding, in the context of subst.c, check_nullness
> is being used as a boolean.  unfortunately, in retrospect the snippets i
> posted are not as clear as i had thought.  (is there a way to provide a URL
> for subst.c that links back to the devel branch at git.savannah.gnu.org?
> as can be done with github or gitlab.)
>
> consider:
>
> * there is only one line where check_nullness is set to a non-zero value.
> * that line is executed at most once.
> * it does check_nullness++ which is another common practice for setting
>   a boolean variable in C code.
>
>  8449   check_nullness++;
>
> * there are at least 2 other references to check_nullness in a boolean
> context:
>
>  8689   if (check_nullness)
>
>  8687   var_is_null = check_nullness && (var_is_set == 0 || *temp == 0);
>
> while these boolean-style references may not prove that check_nullness
> is boolean, it at least shows that using it as a boolean is not
> inconsistent
> with existing practices.
>
> if you agree it's a boolean, wouldn't it be better to test its
> truth/falsity
> directly instead of comparing it to false (0)?  the latter seems like a
> typical "trap" that coding pundits warn against.
>
> consistency would also argue for using the same variable name,
> check_nullness
> (as in my patch) instead of check_null (as in the altered version).
>

Re: compgen -W doesn't split wordlist containing single quotes

[Clark Wang]

On Sat, Mar 17, 2018 at 1:00 AM,  wrote:

>
> It works correctly if the single quote is itself quoted. Our test wordlist
> would then be: "foo\'bar aaa bbb"
>
> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- a
> aaa
> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- b
> bbb
> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- f
> foo'bar
>

This seems to work but it does not. For example in the command line

  # some-cmd f

will become

  # some-cmd foo'bar

then you press ENTER and it'll still wait for another ' char.

Actually every word in the -W "wordlist" needs to be sh-quoted twice (with
``printf %q'' or the new ``${var@Q}'' syntax). It'll be a bit easier if you
use an array. For example:

  # arr=(foo\'bar aaa bbb)
  # for ((i=0; i<${#arr[@]}; ++i)); do arr[i]=$(printf %q "${arr[i]}"); done
  # for ((i=0; i<${#arr[@]}; ++i)); do arr[i]=$(printf %q "${arr[i]}"); done
  # printf '%s\n' "${arr[*]}"
  foo\\\'bar aaa bbb
  # compgen -W "${arr[*]}" -- a
  aaa
  # compgen -W "${arr[*]}" -- f
  foo\'bar

Then in the command line

  # some-cmd f

will become

  # some-cmd foo\'bar

and then you press ENTER and the command will be executed.

-clark

Re: compgen -W doesn't split wordlist containing single quotes

[Clark Wang]

On Sat, Mar 17, 2018 at 7:32 PM, Paulo Marcel Coelho Aragão <
marcelpa...@gmail.com> wrote:

> > Actually every word in the -W "wordlist" needs to be sh-quoted twice
> (with
> > ``printf %q'' or the new ``${var@Q}'' syntax). It'll be a bit easier if
> you
> > use an array.
>
> On a second thought, sh-quoting twice with ${var@Q} won't work as expected
> in this case, since it encloses the expanded value with single quotes, so
> that:
>
> paulo@monk:~/tmp$ arr=(foo\'bar aaa bbb)
> paulo@monk:~/tmp$ arr=(${arr[*]@Q})
> paulo@monk:~/tmp$ arr=(${arr[*]@Q})
> paulo@monk:~/tmp$ echo "${arr[*]}"
> ''\''foo'\''\'\'''\''bar'\''' ''\''aaa'\''' ''\''bbb'\'''
> paulo@monk:~/tmp$ compgen -W "${arr[*]}" -- f
> paulo@monk:~/tmp$
> paulo@monk:~/tmp$ compgen -W "${arr[*]}"
> 'foo'\''bar'
> 'aaa'
> 'bbb'
>
> To produce the desired result, it has to be your original solution, using
> 'printf %q'.
>

Did not know it would break this. I'm still using ``printf %q'' for my
auto-completion code.

Yes ${var@Q} is not compatible with ``printf %q''. The following is what
I've found:

  http://lists.gnu.org/archive/html/bug-bash/2017-10/msg00113.html
  http://lists.gnu.org/archive/html/bug-bash/2017-10/msg00111.html

-clark

Re: compgen -W doesn't split wordlist containing single quotes

[Clark Wang]

On Sun, Mar 18, 2018 at 1:18 AM, Chet Ramey  wrote:

> On 3/17/18 12:16 AM, Clark Wang wrote:
> > On Sat, Mar 17, 2018 at 1:00 AM,  wrote:
> >
> >>
> >> It works correctly if the single quote is itself quoted. Our test
> wordlist
> >> would then be: "foo\'bar aaa bbb"
> >>
> >> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- a
> >> aaa
> >> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- b
> >> bbb
> >> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- f
> >> foo'bar
> >>
> >
> > This seems to work but it does not. For example in the command line
> >
> >   # some-cmd f
> >
> > will become
> >
> >   # some-cmd foo'bar
> >
> > then you press ENTER and it'll still wait for another ' char.
>
> You haven't told complete that you want the words to be quoted. If you
> install the completion using the `-o filenames' option, you will get
> filename-like quoting.
>

`-o filenames' would append `/' to a word if the word is coincidentally a
real existing dir name. How can I ask it not to append the `/'?

-clark

>
> Readline doesn't provide a way to quote completion matches unless you
> say they're filenames. Maybe it should, but that is the way things are.
>

Re: compgen -W doesn't split wordlist containing single quotes

[Clark Wang]

On Mon, Mar 19, 2018 at 9:52 PM, Chet Ramey  wrote:

> > `-o filenames' would append `/' to a word if the word is coincidentally a
> > real existing dir name. How can I ask it not to append the `/'?
>
> You can't. That's the implication from my second paragraph.
>

OK. I'll stick with my 2-pass sh-quoting way.

-clark

weird bash5 bug with ``for i; do echo; done; echo in''

[Clark Wang]

Hi Chet,

Today I compiled bash5 (using default configuration) from the devel branch
(f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks
one of my rc files. After some time of debugging I have the following
minimal example to reproduce the problem:

$ bash5 -c 'for i; do echo; done; echo in'
bash5: -c: line 0: syntax error near unexpected token `in'
bash5: -c: line 0: `for i; do echo; done; echo in'
$

Please take a look.

-clark

Re: Bash patches format

[Clark Wang]

On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer 
wrote:

> > If people are willing to do the conversion between patch formats for
> their
> > own purposes, more power to them. I don't see any compelling reason to
> > change the format I use.
> >
> Could I at least convince you to start doing -p1, if not unified?
>

I think the cost is too high. All bash package maintainers on different
*nix systems will have to change accordingly.

-clark

Re: why is dash confused with underscore in autocompletion?

[Clark Wang]

On Wed, May 30, 2018 at 7:15 AM, L A Walsh  wrote:

> While I certainly don't mind having an option
> to include -_ as case-variations, I don't really like having it
> as a standard or a default
>

I never know there's such a "completion-map-case" option. It is by default
OFF.

Re: cat<(echo text) not same as cat <(echo text)

[Clark Wang]

On Mon, Jun 4, 2018 at 11:48 AM, Edward Huff  wrote:

> That is unexpected.
>

I agree it may look "unexpected" because "cat

Re: Case of set -e not being in effect in a subshell.

[Clark Wang]

On Mon, Jun 11, 2018 at 6:12 PM, Bartłomiej Palmowski 
wrote:

>
> The issue is:
> $ cat bad
> (
> set -e
> false
> echo "Shouldn't happen?"
> ) && :
> $ bash ./bad ; echo $?
> Shouldn't happen?
> 0
> $ cat good
> (
> set -e
> false
> echo "Shouldn't happen?"
> )
> $ bash ./good ; echo $?
> 1
>
> Probably there is something obvious that I'm missing.
>

According to bash man page:

> The shell does not exit if the command that fails is [...] part of any
command executed in a && or || list except the command following the final
&& or ||, [...]

-clark

Re: Variables can’t contain NUL

[Clark Wang]

On Wed, Jun 20, 2018 at 10:22 PM, George  wrote:

>
> Personally I do think some method of handling arbitrary binary data in the
> shell would be a welcome addition (and I think zsh provides that - don't
> remember if ksh does)
>

Ksh93 has "typeset -b" which defines vars for binary data (actually base64
encoded). E.g.:

[STEP 100] $ echo ${.sh.version}
Version AJM 93u+ 2012-08-01
[STEP 101] $ typeset -b var
[STEP 102] $ var=$( echo hello world | base64 )
[STEP 103] $ echo $var
aGVsbG8gd29ybGQK
[STEP 104] $ printf %B var
hello world
[STEP 105] $

Re: remove empty '' in ${var@Q} result?

[Clark Wang]

On Wed, Nov 8, 2017 at 9:46 PM Chet Ramey  wrote:

> On 11/7/17 11:38 PM, Clark Wang wrote:
>
> > I made a patch (also attached). Please see if it's ok.
> >
> >
> > Updated by dealing with empty strings (and malloc'ing 2 more bytes)
> > though I'm not sure if it's necessary since the func
> > sh_quote_reusable() already handles empty strings.
> >
> >
> > Hi Chet, do you have a look at my patch?
>
> I did. It's on the list of possible things for the next version. Since it's
> only a cosmetic issue, it's not a high priority.
>

Hi Chet,

Is it possible to make the change in the coming 5.0 release?

-clark

bash-5.0-beta2 breaks ``complete -D''

[Clark Wang]

Hi Chet,

Just tried 5.0-beta2 and it broke my completion rules. It can be reproduced
with the following steps:

# complete -r
# foo() { true; }
# complete -o default -o bashdefault -D -F foo
# cd /<-- Here it does not list dirs under `/'. Works fine
with 4.4.

Please take a look.

-clark

Re: FIFO race condition on SunOS kernels

[Clark Wang]

On Wed, Jan 2, 2019 at 8:38 PM Vladimir Marek 
wrote:

> >
> > Thanks, that's good to have confirmed! It was hoping as much -- it would
> > have been hard to believe that something this basic is broken on Solaris
> in
> > general.
>
> Heh :) I am heavy shell scripter/user and I have found multiple bugs in
> various shells. But I don't remember single issue with bash.
>

I've been using Bash for ~15 years (from v2.05 to v5.0) and only hit a few
bugs. I started using Ksh (ksh93 on Solaris 11+) in 2011 and reported ~40
bugs (for very basic features) in 1~2 years. I guess that's because ksh93
was not opensource before so there were not enough users testing it.

-clark

bash5: "progcomp_alias" and "complete -D"

[Clark Wang]

Seems like if there's "complete -D" defined then "progcomp_alias" would
never work. So does it make more sense to make "progcomp_alias" has higher
priority than "complete -D"?

Re: Where is GLOBAL_COMMAND?

[Clark Wang]

On Tue, Jan 22, 2019 at 1:32 PM Peng Yu 
mailto:pengyu...@gmail.com>> wrote:
Hi,

GLOBAL_COMMAND is mentioned as a global variable. But I don't find it.
Is it renamed to something else?

execute_cmd.c
373-
374-/* Execute the command passed in COMMAND.  COMMAND is exactly what
375:   read_command () places into GLOBAL_COMMAND.  See "command.h" for the
376-   details of the command structure.

In command.h it has this:

  extern COMMAND *global_command;

Re: Forgets color when resizing with newline in prompt

[Clark Wang]

On Sun, Oct 6, 2019 at 12:17 AM ao2  wrote:

> [...]
>
> Description:
>
> I noticed that when there is a newline in the prompt bash "forgets"
> about ANSI color sequences when the window is resized. I am not
> sure
> f this is general for other kinds of ANSI escape codes.
>
> Repeat-By:
>
> 1. Set the prompt to something like:
>
>  PS1='\[\033[36m\]cyan\ncyan\[\033[0m\]\$ '
>
>or equivalently to:
>
>  PS1='\[$(tput setaf 6)\]cyan\ncyan\[$(tput sgr0)\]\$ '
>
> 2. Resize the terminal window and see the second line of the prompt
>loosing the color.
>

Did a strace when resizing the tty and it outputs this:

ioctl(0, TIOCGWINSZ, {ws_row=73, ws_col=228, ws_xpixel=0, ws_ypixel=0})
= 0
write(2, "\r\33[Kcyan\33[m\17# ", 14)   = 14

So it seems like Bash only reprint the last line of the prompt string when
SIGWINCH is received.

\r -- move cursor to the beginning of current line
\33[K -- clear from cursor to the end of the line


I don't think this is a bug and your workaround should be the best
practice. :)

-clark

Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?

[Clark Wang]

It's quite common for people to press CTRL-C to discard the current command
line. This is harmless actually for most times except when people include
$? in $PS1. I also show $? in red color when it's not 0 so it's more
noticeable. So is it OK to not change $? when people are pressing CTRL-C to
discard the input?

-clark

Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?

[Clark Wang]

On Fri, Nov 22, 2019 at 12:02 AM Chet Ramey  wrote:

>
> This behavior dates from at least 2009 and was added at user request so
> they could tell exactly that: whether or not entering the last command had
> been interrupted by a signal.
>

Curious why people care about this?

-clark

Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?

[Clark Wang]

Hi Chet,

On Fri, Nov 22, 2019 at 12:02 AM Chet Ramey  wrote:

> On 11/20/19 9:27 PM, Clark Wang wrote:
> > It's quite common for people to press CTRL-C to discard the current
> command
> > line. This is harmless actually for most times except when people include
> > $? in $PS1. I also show $? in red color when it's not 0 so it's more
> > noticeable. So is it OK to not change $? when people are pressing CTRL-C
> to
> > discard the input?
>
> This behavior dates from at least 2009 and was added at user request so
> they could tell exactly that: whether or not entering the last command had
> been interrupted by a signal.
>

I don't know how many people count on this behavior. Is it possible this be
fixed?

-clark

An exported function is malformed if it contains a nested function definition with heredoc

[Sherwood Wang]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-
5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux hostname 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1
(2020-01-26) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 3
Release Status: release

Description:

A function containing a nested function definition with heredoc
cannot be serialized into the environment variable correctly,
and leads to failures in a subshell.

See also: 
https://stackoverflow.com/questions/60564674/exporting-a-function-with-a-nested-function-definition-and-heredoc-in-bash

Repeat-By:

Create a script:

#!/bin/bash

f() {
g() {
cat <

"shell-expand-line" wrongly(?) expanded $'foo' to $foo

[Clark Wang]

See the following example (tested with bash 5.0.7):


# bind -q shell-expand-line
shell-expand-line can be invoked via "\e\C-e".

# echo $PWD  # press ESC C-e
# echo /root

# echo $( pwd )  # press ESC C-e
# echo /root

# echo $'foo'# press ESC C-e
# echo $foo


Is this a bug?

-clark