Re: [5.3-alpha] ">& /some/file" would fail when /some/file already exists

[Clark Wang]

On Fri, Apr 26, 2024 at 2:53 AM Chet Ramey  wrote:
>
> I can't reproduce it on macOS.
>
> $ ./bash --norc
> $ touch some.file
> $ echo >
> $ rm some.file
> $ touch /tmp/file
> $ echo >& /tmp/file
> $ rm /tmp/file
> $ echo $BASH_VERSION
> 5.3.0(1)-alpha

I was using Debian (not sure about the exact version) of WSL2 on
Windows 11. Just tried on macOS (x64) and a Debian 10.13 VM (x64) but
both failed to repro. Weird.

Re: Bash-5.3-alpha available

[Clark Wang]

On Tue, Apr 23, 2024 at 9:20 PM Chet Ramey  wrote:
> [..]
>
> and from the bash-5.3-testing branch in the bash git repository
> (http://git.savannah.gnu.org/cgit/bash.git/log/?h=bash-5.3-testing).
> You can use
>
> git clone --branch bash-5.3-testing git://git.savannah.gnu.org/bash.git
>
> to clone the testing branch.

On the "bash-5.3-testing" branch ./configure reported error:

$ ./configure --prefix=/some/path
[..]
checking whether /dev/stdin stdout stderr are available... present
checking for default mail directory... /var/mail
checking shared object configuration for loadable builtins... supported
cp: cannot stat './include/stdckdint.in.h': No such file or directory
configure: creating ./config.status
config.status: creating Makefile
config.status: creating builtins/Makefile
[..]

And then make would fail:

$ make
make: *** No rule to make target 'include/unlocked-io.h', needed by
'shell.o'.  Stop.

[5.3-alpha] ">& /some/file" would fail when /some/file already exists

[Clark Wang]

(I'm using the "devel" branch as the "bash-5.3-testing" branch failed
to build for me. HEAD: 8c8daff1e3661c)

To reproduce:

$ bash53 --norc
bash53-5.3# touch /tmp/file
bash53-5.3# echo >& /tmp/file
bash53: /tmp/file: File exists
bash53-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.

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?

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?

[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: RFE: new syntax for command substitution to keep trailing newlines?

[Clark Wang]

On Wed, Jan 27, 2021 at 4:40 PM Clark Wang  wrote:

> On Wed, Jan 27, 2021 at 12:14 PM Clark Wang  wrote:
>
>> For example, we can use ${( ... )} which is now wrong syntax.
>>
>> $ v=${( command ... )}
>> bash: ${( command ... )}: bad substitution
>>
>
> Or keep it similar to $(cmd), like:
>
>   $(& cmd ...)
>   $(; cmd ...)
>   $(| cmd ...)
>

$(|cmd ...) makes more sense for me. '|' is a pipe which means passthrough.

For future extensions, use

  $([=value1][=value2] cmd ...)

For example,

  $(_trailing_newlines cmd ...) is just the same as $(|cmd ...).
  $(_fork cmd ...) means the ksh style ${ cmd ... }.

Re: RFE: new syntax for command substitution to keep trailing newlines?

[Clark Wang]

On Wed, Jan 27, 2021 at 12:14 PM Clark Wang  wrote:

> For example, we can use ${( ... )} which is now wrong syntax.
>
> $ v=${( command ... )}
> bash: ${( command ... )}: bad substitution
>

Or keep it similar to $(cmd), like:

  $(& cmd ...)
  $(; cmd ...)
  $(| cmd ...)

RFE: new syntax for command substitution to keep trailing newlines?

[Clark Wang]

For example, we can use ${( ... )} which is now wrong syntax.

$ v=${( command ... )}
bash: ${( command ... )}: bad substitution

Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)

[Clark Wang]

On Tue, Dec 8, 2020 at 12:36 PM Testing Purposes <
raspberry.teststr...@gmail.com> wrote:

> But Readline's official documentation specifically chose an example with a
> leading zero — 0x0402.  It says that Readline 4.2 should have a version
> value of 0x0402, not 0x402.
>

Could you point me to where it says 0x402 is wrong?

>
> Therefore, based on the documentation, there should still be a way to
> extract the full, 0xMMmm-formatted value for rl_readline_version.
>
> The Readline documentation explicitly states that the value should consist
> of a "*two-digit* major version number" (MM) plus a "*two-digit* minor
> version number" (mm).  In other words, the output format should always
> be 0xMMmm.
>

I'd interpret the two-digit as "at most two digits". For 0x402, MM is "04"
and mm is "02".

>
> All contemporary versions of Readline consist of a single-digit integer
> for the major version number.  That won't change until we get to version 10
> of Readline.
>

It sounds to me that the "two digits" are in HEX format (0xMMmm) so when it
reaches version 10 it'll be 0x0a00.


> That means, for now, all major version numbers of Readline, when formatted
> as a two-digit number, would always contain a leading zero — so there's
> nothing unusual about this scenario.
>
> So there should be a way to extract the full and proper 0xMMmm format, as
> the example in the documentation indicates.
>

You can

$ printf '0x%04x\n' 0x402
0x0402
$ printf '0x%04x\n' 0x801
0x0801
$

>

Re: Bash 5.1: rl_readline_version = 0x801 (shouldn't it be 0x0801 ?)

[Clark Wang]

On Tue, Dec 8, 2020 at 10:04 AM Testing Purposes <
raspberry.teststr...@gmail.com> wrote:

> --
> readline.h defines a C preprocessor variable that should be treated as an
> integer,


As it says it's an integer.


> RL_READLINE_VERSION, which may be used to conditionally compile
> application code depending on the installed Readline version. The value is
> a hexadecimal encoding of the major and minor version numbers of the
> library, of the form 0xMMmm. MM is the two-digit major version number; mm
> is the two-digit minor version number. For Readline 4.2, for example, the
> value of RL_READLINE_VERSION would be 0x0402.
> --
>
> If the version number for readline follows the "0xMMmm" format, shouldn't
> the value of "rl_readline_version" be "0x0801" for Bash 5.1 and "0x0800"
> for Bash 5.0?  In other words, the "leading 0" after the "x" appears to be
> missing.


The integer 0x801 is the same as 0x0801.

# echo $(( 0x801 ))
2049
# echo $(( 0x0801 ))
2049
# echo $(( 0x0801 ))
2049
#

Re: is it a bug

[Clark Wang]

On Mon, Nov 16, 2020 at 9:38 PM Robert Elz  wrote:

>
> Personally I'd go further and suggest that no-one should ever use aliases
> for anything, ever ...
>

I don't understand why people "hate" aliases so much. :) For me it's much
simpler/shorter than functions. And the "alias" command (without any
options) output is more compact than "declare -f". Just take a look at some
of my aliases (I have ~150 aliases in total):

alias B='builtin'
alias C='command'
alias D='date'
alias E='export'
alias F='find'
alias G='git'
alias H='history'
alias I='ifconfig'
alias K='killall'
alias L='less'
alias M='LC_ALL=C MANWIDTH=$(( COLUMNS > 120 ? 120 : COLUMNS )) man'
alias N='netstat'
alias O='openssl'
alias P='patch'
alias R='route'
alias T='touch'
alias U='uname'
alias V='echo $BASH_VERSION'
alias W='watch'
alias X='screen -X'
alias Z='reset'
alias a='alias'
alias b='builtin cd -'
alias c='clear'
alias d='diff'
alias e='echo'
alias f='file'
alias g='grep'
alias h='help'
alias i='command info'
alias j='jobs'
alias k='kill'
alias l='ls -l'
alias m='make'
alias n='mount'
alias p='patch'
alias q='exit'
alias r='fc -s'
alias s='screen'
alias t='type'
alias u='umount'
alias v='vim'
alias x='xargs'
alias z='echo "${COLUMNS}x$LINES ${TERM:+($TERM)}"'

Re: possible bugs with colored-stats

[Clark Wang]

On Thu, Oct 29, 2020 at 4:11 AM Arnaud  wrote:

>
> Description:
> I have colored my prompt with colors, using PS1 and PS0.
>
> PS1 ends with a color definition, so the command entered is
> colored.
> PS0 resets the color so the output has the standard colors.
> I have actived colored-stats, so when I use tab completion, the
> colors I use in the command doesn't show in the tab completion.
>
> Problem 1
> If the list starts with a file, only the 1st file is colored with
> the PS1 color.
> If the list starts with a folder, the colors are ok.
>
> Problem 2
> when I list the content of a folder with ls, the color is ok
> (white in my case, until I reach a folder,
> it then switches the color of the following files to grey.
>
> I tried looking in the bash code to try to find the problem, but I
> cannot locate the part of the code for that (not experienced in C)
> Normally, readline should be the part I am looking for, but I also
> have readline installed in my system, so it should be in it?
> (tried to remove the readline package in my system to be sure, but
> it wants to remove systemd, so I didn't)
>
> it seems to also do this with 5.1-rc1
>
> Repeat-By:
> add "set colored-stats on" in ~/.inputrc (may need to restart the
> shell)
> add at the end of PS1: "(\[\€[38;5;220m\]" , for example
> add for PS0: "\[\e[38;5;15m\]"
>

I can reproduce the similar issue with my bash 4.4.12 and PS0="\[\e[0m\]"
fix it for me.

-clark

Re: bash -c 'sleep 5 &' vs. ssh user@host 'sleep 5 &'

[Clark Wang]

On Tue, Sep 22, 2020 at 5:07 PM Robert Elz  wrote:

>
> With -t, there's no pty, when the shell exits, everything ends up
> closed - but the mechanism for this escapes me (what bash &/or sshd
> sees differently).   You'd do better to ask on an ssh related list
> I expect.
>

Found the question at https://unix.stackexchange.com/questions/346549/ .
The accepted answer does not look correct to me. Posted a new answer there.

-clark

Re: bash -c 'sleep 5 &' vs. ssh user@host 'sleep 5 &'

[Clark Wang]

On Tue, Sep 22, 2020 at 2:01 PM Robert Elz  wrote:

> Date:Tue, 22 Sep 2020 10:02:07 +0800
> From:    Clark Wang 
> Message-ID:  <
> cadv8-ogf0hev-ckegxy9dq1ypcz4bdpkjy_7aex83o1db93...@mail.gmail.com>
>
>   | In an interactive shell (in case this matters), run bash -c 'sleep 5
> &' and
>   | it exits immediately without waiting for the sleep to complete. But ssh
>   | user@host 'sleep 5 &' (with bash as the login shell) would wait for
> sleep
>   | to complete. Why the difference?
>
> It isn't bash waiting for the sleep to complete, it is ssh waiting for
> the connection to close.  Neither ssh nor the sshd at the target know that
> "sleep" doesn't write any output, so they have to keep the connection alive
> (and hencs ssh running on the client end) until the command has completed
> (actually, until it closes its fds, so you could do
>
> ssh user@host 'sleep 5 >&- 2>&- &'
>
> if you wanted (no need to worry about stdin, because it is an async
> process, that gets connected to /dev/null anyway).   This shows
> stdout & stderr being closed - that part is not important (just the
> briefest sane example to give) - you could also redirect them to
> anywhere else (just remember that it has to be both of them).
>

Ah right. I misunderstood something else. When I run

  $ ssh 127.0.0.1 '{ sleep 120 | cat; } & exit'

and on another tty I did this

  $ pgrep -af sleep
  83207 ssh 127.0.0.1 { sleep 120 | cat; } & exit
  83215 bash -c { sleep 120 | cat; } & exit
  83216 sleep 120

I wrongly thought the process 'bash -c ...' in pgrep's output is the parent
bash but it should be the forked child bash.

Then, how should we explain that

  $ ssh -t 127.0.0.1 'sleep 120 &'

would complete immediately?

-clark

bash -c 'sleep 5 &' vs. ssh user@host 'sleep 5 &'

[Clark Wang]

In an interactive shell (in case this matters), run bash -c 'sleep 5 &' and
it exits immediately without waiting for the sleep to complete. But ssh
user@host 'sleep 5 &' (with bash as the login shell) would wait for sleep
to complete. Why the difference?

Thanks.

-clark

"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

Different history expansion behaivor: true `# # !xxx` vs. true `# !xxx`

[Clark Wang via Bug reports for the GNU Bourne Again SHell]

This is from stackoverflow ( https://stackoverflow.com/questions/60166019/ ) 
and it looks like a bug:

$ bash --version
GNU bash, version 5.0.7(3)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 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.
$
$ set -H
$ true `# !xxx`
bash: !xxx`: event not found
$ true `# # !xxx`
$

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

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

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;

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

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

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

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

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

[Clark Wang]

On Sun, Mar 18, 2018 at 1:18 AM, Chet Ramey <chet.ra...@case.edu> wrote:

> On 3/17/18 12:16 AM, Clark Wang wrote:
> > On Sat, Mar 17, 2018 at 1:00 AM, <marcelpa...@gmail.com> 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 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 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: 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: 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]

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: 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: 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 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 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: 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: 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: 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: set $'\001'; v=$* converted $'\001' to $'\001\001'

[Clark Wang]

On Mon, Jan 15, 2018 at 11:44 PM, Chet Ramey <chet.ra...@case.edu> 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

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] #

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.

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

[Clark Wang]

On Tue, Oct 31, 2017 at 3:53 PM, Clark Wang <dearv...@gmail.com> wrote:

> On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang <dearv...@gmail.com> wrote:
>
>> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey <chet.ra...@case.edu> 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?

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

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 Tue, Oct 31, 2017 at 3:25 PM, Clark Wang <dearv...@gmail.com> wrote:

> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey <chet.ra...@case.edu> 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

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

${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: Documentation issue

[Clark Wang]

On Fri, Oct 27, 2017 at 3:28 PM, Eli Barzilay <e...@barzilay.org> wrote:

> On Fri, Oct 27, 2017 at 2:37 AM, Clark Wang <dearv...@gmail.com> 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.

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

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

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: A background ssh can take over the tty from bash?

[Clark Wang]

On Tue, Jun 13, 2017 at 11:00 AM, L A Walsh  wrote:

>
>In this case you need to use "-n" with "-f" OR not use
> either if you wish it to be suspended.
>

I did want the `ssh -o ControlMaster=yes` to run as a daemon.


>If I launch ssh without "-f" but put it in background, it doesn't
> grab the foreground terminal (and the DOES get suspended when it
> tries to do input).
>
> Please see my explanation @stackoverflow:
>> https://stackoverflow.com/questions/44492312/ .
>>
>>
> Seems to be saying similar -- that the demonizing process needs
> to be disconnected from stdin.
>

`-f` implies `-n` so it is effectively disconnected from the tty (though
it's still opening the tty device with FDs 0, 1, 2 but it would never read
from FD 0). The magic part here is it's the 2nd `ssh ... sleep` that asks
the 1st `ssh -o ControlMaster=yes` to open (by passing the FDs to it) the
tty again (with new FDs) and read from it.


> It doesn't mention that you can have it be suspended
> (as you seemed to expect), by not having it daemonize.
>

As I mentioned ealier, I don't want the `ssh -o ControlMaster=yes` to be
suspended.

-clark

Re: A background ssh can take over the tty from bash?

[Clark Wang]

On Tue, Jun 13, 2017 at 2:48 AM, L A Walsh <b...@tlinx.org> wrote:

> Clark Wang wrote:
>
>>
>> I've checked the ssh process and it does not catch SIGTTIN and that's why
>> I'm confused.
>>
>>
> 
>From what I understand, a background process will automatically
> block when it tries to read from STDIN.  By definition, processes
> become bg-processes by using '&'.  I haven't looked at the
> code, but I'm guessing that the first 'ssh' that you launched
> (*without* the '&') is the process swallowing your input as
> it was declared to be a some sort of master-multiplexer for
> subsequent slave processes, but that's just a guess.  Maybe
> putting the master in background @ launch (using '&') will
> cause it to auto-block(suspend) as you expect?
>

The first ssh (with `-f`) would fork another ssh running as a daemon which
would detach from the current tty. It makes no difference whether to use
`&` or not. Please see my explanation @stackoverflow:
https://stackoverflow.com/questions/44492312/ .

-clark

Re: A background ssh can take over the tty from bash?

[Clark Wang]

On Mon, Jun 12, 2017 at 10:48 PM, Chet Ramey  wrote:

> >
> > This has come up before. You need to use `ssh -n' to avoid it
> reading from
> > stdin. Processes can ignore SIGTTIN, and ssh does so to avoid being
> stopped
> > if it reads from the tty while in the background.
> >
> >
> > I've checked the ssh process and it does not catch SIGTTIN and that's why
> > I'm confused.
>
> OK. This has gone beyond the realm of a bash bug. I'm pretty sure that
> previous versions of ssh ignored or caught SIGTTIN, but it must not do that
> now.
>
> Since ssh has a handle on its controlling terminal, it must do something
> that allows it to read from it even if it's not in the foreground process
> group. In any event, -n is the way to deal with that.
>

Thanks Chet.

I reposted the question to stackoverflow this morning and just managed to
figure out the problem (see https://stackoverflow.com/questions/44492312/ ).

-clark

Re: A background ssh can take over the tty from bash?

[Clark Wang]

On Mon, Jun 12, 2017 at 5:48 AM, Chet Ramey <chet.ra...@case.edu> wrote:

> On 6/10/17 10:19 AM, Clark Wang wrote:
>
> > If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
> > 127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my
> input
> > again. Seems like the background "ssh" at tty #1 is consuming all input.
> I
> > cannot understand this since it should be stopped by SIGTTIN if it tries
> to
> > read from the tty.
>
> This has come up before. You need to use `ssh -n' to avoid it reading from
> stdin. Processes can ignore SIGTTIN, and ssh does so to avoid being stopped
> if it reads from the tty while in the background.
>

I've checked the ssh process and it does not catch SIGTTIN and that's why
I'm confused.

$ ps p937
   PID TTY  STAT   TIME COMMAND
   937 pts/2S  0:00 ssh -o ControlMaster=no -o
ControlPath=/tmp/socket.ssh 127.0.0.1 sleep 
$ ps s p937
  UIDPID  PENDING  BLOCKED  IGNORED
CAUGHT STAT TTYTIME COMMAND
0937   1000
000188004003 Spts/2  0:00 ssh -o ControlMaster=no -o
ControlPath=/tmp/socket.ssh 127.0.0.1 sleep 
$

The decoded sig masks are:

PENDING ():
BLOCKED ():
IGNORED (1000):
  13 PIPE
CAUGHT (000188004003):
   1 HUP
   2 INT
  15 TERM
  28 WINCH
  32
  33

Re: A background ssh can take over the tty from bash?

[Clark Wang]

On Sat, Jun 10, 2017 at 11:00 PM, John McKown <john.archie.mck...@gmail.com>
wrote:

> On Sat, Jun 10, 2017 at 9:19 AM, Clark Wang <dearv...@gmail.com> wrote:
>
>> (I'm using bash 4.4.12 on Debian 8)
>>
>> Please follow the following steps to reproduce.
>>
>> From tty #1:
>>
>> $ tty
>> /dev/pts/11
>> $ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
>> root@127.0.0.1's password:
>> $ ps -C ssh uw
>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>> root   716  0.0  0.2  44428   692 ?Ss   22:04   0:00 ssh -o
>> ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
>> $
>> $
>> ​​
>> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
>>  &
>> [1] 725
>> $<-- Then I cannot input anything except CTRL-C
>>
>> Go to tty #2:
>>
>> $ ps t pts/11 jw
>>  PPID   PID  PGID   SID TTY  TPGID STAT   UID   TIME COMMAND
>> 32714   725   725 32714 pts/11   32714 S0   0:00 ssh -o
>> ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
>>   579 32714 32714 32714 pts/11   32714 Ss+  0   0:00 bash
>> $
>>
>> If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
>> 127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my
>> input
>> again. Seems like the background "ssh" at tty #1 is consuming all input. I
>> cannot understand this since it should be stopped by SIGTTIN if it tries
>> to
>> read from the tty.
>>
>> Idea?
>>
>> -clark
>>
>
> ​IMO, not a bug in BASH, so this is the wrong forum. But, since I'm
> already blathering on, I'd say the problem is that you have invoked "ssh"
> incorrectly.​ In particular, ssh _does_ read from stdin normally. But, from
> the man page:
>
>  -f  Requests ssh to go to background just before command execution.
> This is useful if ssh is going to ask for passwords
>  or passphrases, but the user wants it in the background.
> This implies -n.  The recommended way to start X11 programs
>  at a remote site is with something like ssh -f host xterm.
>
>  If the ExitOnForwardFailure configuration option is set to
> “yes”, then a client started with -f will wait for all
>  remote port forwards to be successfully established before
> placing itself in the background.
>
>
> So instead of:
>
> ​
> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
> &
>
> Try:
>
> ​
> ssh -f -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
> 
>

Thanks but I want it to run as a background job in bash.

A background ssh can take over the tty from bash?

[Clark Wang]

(I'm using bash 4.4.12 on Debian 8)

Please follow the following steps to reproduce.

>From tty #1:

$ tty
/dev/pts/11
$ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
root@127.0.0.1's password:
$ ps -C ssh uw
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   716  0.0  0.2  44428   692 ?Ss   22:04   0:00 ssh -o
ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
$
$ ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
 &
[1] 725
$<-- Then I cannot input anything except CTRL-C

Go to tty #2:

$ ps t pts/11 jw
 PPID   PID  PGID   SID TTY  TPGID STAT   UID   TIME COMMAND
32714   725   725 32714 pts/11   32714 S0   0:00 ssh -o
ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
  579 32714 32714 32714 pts/11   32714 Ss+  0   0:00 bash
$

If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my input
again. Seems like the background "ssh" at tty #1 is consuming all input. I
cannot understand this since it should be stopped by SIGTTIN if it tries to
read from the tty.

Idea?

-clark

``shopt -s extglob'' and ``function @() { true; }''

[Clark Wang]

There is a post on stackoverflow:
http://stackoverflow.com/questions/43117707/bashs-strange-behavior-on-a-function-named/

The *problem*:

bash-4.4# shopt -s extglob
bash-4.4# function @() { echo foo; }
bash-4.4# @()
foo
bash-4.4# declare -f
@() ()
{
echo foo
}
bash-4.4#
bash-4.4# unset -f '@()'
bash-4.4#
bash-4.4# shopt -s nullglob
bash-4.4# function @() { echo foo; }
bash-4.4# @()
bash-4.4# declare -f
@() ()
{
echo foo
}
bash-4.4#

So when extglob is on, @() is handled as a glob pattern which makes sense.
But the behavior after shopt -s nullglob indicates that the glob pattern @()
is not *filename-expand*ed for function @(). This looks kind of
counter-intuitive to me.

Bug or feature?

-clark
​

Re: Strange bash behavior

[Clark Wang]

On Fri, Dec 2, 2016 at 6:34 PM, Vladimir Marek 
wrote:

> Nice analysis, does the second example look similar?
>
> bash -c 'bash -i 1; read -t 2 a < /dev/tty'
>

I think it's the same problem. After "bash -i" exited, "bash -c" is not the
controlling process any more so it cannot read from the tty.

Re: Strange bash behavior

[Clark Wang]

On Fri, Dec 2, 2016 at 12:59 PM, Clark Wang <dearv...@gmail.com> wrote:

> On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek <vladimir.ma...@oracle.com>
> wrote:
>
>> Hi,
>>
>> I'm not sure what is going on, but the bash test suite was getting
>> stopped (as if SIGSTOP was received) in the middle. Trying to find
>> minimal set of conditions it came to this:
>>
>>  - my ~/.bashrc has to contain 'cd /' (any dir works)
>>  - the tests have to first execute run-execscript, namely it has to
>>execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
>>  - the file exec8.sub is reported as not found (I presume because of the
>>'cd /' in .bashrc)
>>  - the tests then have to run read-test, exactly in read2.sub when
>>  'read -t 2 a < /dev/tty' was executed whole thing was stopped
>>
>> When I removed the 'cd' command from my ~/.bashrc, all worked fine.
>>
>> I then tried to make minimal reproducible case and came to this (this
>> time there is no 'cd /' in my ~/.bashrc needed):
>>
>> $ bash -c 'bash -i i; bash -i i'
>> bash -c 'bash -i i; bash -i i'
>> bash: i: No such file or directory
>>
>> [1]+  Stopped bash -c 'bash -i i; bash -i i'
>>
>
> I can reproduce this with bash 4.4.5 on Debian 8.5.
>
>   foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
>   bash: 1: No such file or directory
>
>   [1]+  Stopped bash -c 'bash -i 1; bash -i 2'
>   foo@deb64:~$ echo $?
>   149
>
> It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
> second "bash -i".
>
>   4099   while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
>   4100 {
>   4101   if (shell_pgrp != terminal_pgrp)
>   4102 {
>   4103   SigHandler *ottin;
>   4104
>   4105   ottin = set_signal_handler (SIGTTIN, SIG_DFL);
>   4106   kill (0, SIGTTIN);
>   4107   set_signal_handler (SIGTTIN, ottin);
>   4108   continue;
>   4109 }
>   4110   break;
>   4111 }
>
> The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
> when the second "bash -i" is running. This can be shown with following
> example:
>
>   foo@deb64:~$ bash -c 'bash -i 1; sleep '
>   bash: 1: No such file or directory<-- CTRL-C does not work here
>
>   root@deb64:~# ps t pts/10 j
> PPIDPID   PGIDSID TTY   TPGID STAT   UID   TIME COMMAND
>96886  96887  96887  96887 pts/1097073 Ss1001   0:00 -bash
>96887  97072  97072  96887 pts/1097073 S 1001   0:00 bash -c
> bash -i 1; sleep 
>97072  97074  97072  96887 pts/1097073 S 1001   0:00 sleep 
>
> Here the TPGID 97073 must be the first "bash -i" which has already exited.
> Seems like for some reason the "bash -c" does not set the foreground pgrp
> to the second "bash -i".
>

Found the problem. The first "bash -i" changed the foreground pgrp to its
own pgrp at startup but did not restore the original foreground pgrp when
it exited. The following patch (not a real fix) works for me:

--- a/shell.c
+++ b/shell.c
@@ -1504,6 +1504,7 @@ open_shell_script (script_name)
 {
   e = errno;
   file_error (filename);
+  end_job_control ();
   sh_exit ((e == ENOENT) ? EX_NOTFOUND : EX_NOINPUT);
 }

Re: Strange bash behavior

[Clark Wang]

On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek 
wrote:

> Hi,
>
> I'm not sure what is going on, but the bash test suite was getting
> stopped (as if SIGSTOP was received) in the middle. Trying to find
> minimal set of conditions it came to this:
>
>  - my ~/.bashrc has to contain 'cd /' (any dir works)
>  - the tests have to first execute run-execscript, namely it has to
>execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
>  - the file exec8.sub is reported as not found (I presume because of the
>'cd /' in .bashrc)
>  - the tests then have to run read-test, exactly in read2.sub when
>  'read -t 2 a < /dev/tty' was executed whole thing was stopped
>
> When I removed the 'cd' command from my ~/.bashrc, all worked fine.
>
> I then tried to make minimal reproducible case and came to this (this
> time there is no 'cd /' in my ~/.bashrc needed):
>
> $ bash -c 'bash -i i; bash -i i'
> bash -c 'bash -i i; bash -i i'
> bash: i: No such file or directory
>
> [1]+  Stopped bash -c 'bash -i i; bash -i i'
>

I can reproduce this with bash 4.4.5 on Debian 8.5.

  foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
  bash: 1: No such file or directory

  [1]+  Stopped bash -c 'bash -i 1; bash -i 2'
  foo@deb64:~$ echo $?
  149

It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
second "bash -i".

  4099   while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
  4100 {
  4101   if (shell_pgrp != terminal_pgrp)
  4102 {
  4103   SigHandler *ottin;
  4104
  4105   ottin = set_signal_handler (SIGTTIN, SIG_DFL);
  4106   kill (0, SIGTTIN);
  4107   set_signal_handler (SIGTTIN, ottin);
  4108   continue;
  4109 }
  4110   break;
  4111 }

The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
when the second "bash -i" is running. This can be shown with following
example:

  foo@deb64:~$ bash -c 'bash -i 1; sleep '
  bash: 1: No such file or directory<-- CTRL-C does not work here

  root@deb64:~# ps t pts/10 j
PPIDPID   PGIDSID TTY   TPGID STAT   UID   TIME COMMAND
   96886  96887  96887  96887 pts/1097073 Ss1001   0:00 -bash
   96887  97072  97072  96887 pts/1097073 S 1001   0:00 bash -c
bash -i 1; sleep 
   97072  97074  97072  96887 pts/1097073 S 1001   0:00 sleep 

Here the TPGID 97073 must be the first "bash -i" which has already exited.
Seems like for some reason the "bash -c" does not set the foreground pgrp
to the second "bash -i".

(Still learning the APUE book. Hope my analysis makes sense. :)

Re: ``read -N n -t timeout'' saves partial input only when EOF is seen?

[Clark Wang]

On Fri, Nov 25, 2016 at 7:05 AM, L A Walsh  wrote:

>
>
> isabella parakiss wrote:
>
>> that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734
>> read successfully reads the data, but then it's discarded by bash
>>
>>
> 
>It's discarded by bash because the read doesn't read 10
> characters within the time limit.  If you use -N 5, you get
> your output.   "-t" says it will timeout and return failure if a
> specified number of characters is not read within timeout period.
>

The manual for -t says:

If read times out, read saves any partial input read into the specified
variable *name*.

-clark
​

If timeout is exceeded, then return status is > 128:
>
> bash -c '( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "s=$?,
> <$v>" )'
> s=142, <>
>
> (status is > 128)
>
>
>>
>

``read -N n'' removes leading "\n"s

[Clark Wang]

See following example:

[STEP 100] # echo $BASH_VERSION
4.4.5(2)-release
[STEP 101] # read -N 5 v
abcd
[STEP 102] # printf '%q\n' "$v"
$'abcd\n'
[STEP 103] # read -N 5 v


abc[STEP 104] # printf '%q\n' "$v"
abc
[STEP 105] #

The second read did not return the leading "\n"s. According to the manual
of read -N, "the result is not split on the characters in IFS" but I'm not
sure how to understand this. Is the behavior correct?

Thanks.

-clark

``read -N n -t timeout'' saves partial input only when EOF is seen?

[Clark Wang]

See following example:

# echo $BASH_VERSION
4.4.5(2)-release
# ( printf 12345 ) | ( read -t 1 -N 10 v; echo "<$v>" )
<12345>
# ( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "<$v>" )
<>
#

The second "read" did not save "12345" to "v". Is this a bug?

-clark

Re: bind -m vi-insert '"jj": "\e"' problem in 4.4

[Clark Wang]

On Fri, Nov 4, 2016 at 6:36 PM, Clark Wang <cla...@vmware.com> wrote:

> For example, in vi-insert mode I input following in the command line:
>
> # foo abc
>
> The cursor is right after 'c'. Now if I press ESC then it'll go to
> vi-command mode and the cursor will move to under 'c'. But if I press jj
> the cursor would be still after 'c' and if then I press h the cursor will
> skip 'c' and move to under 'b' . In 4.3, ESC and jj works the same so there
> must be something changed in 4.4. Please take a look.
>

The following workaround works fine for me:

  bind -m vi-insert '"jj": "\e\e"'# double ESC :)

-clark

Re: [Help-bash] How to make vi-insert mode's ctrl-w work in the 4.3 way?

[Clark Wang]

On Fri, Nov 4, 2016 at 10:32 PM, Chet Ramey <chet.ra...@case.edu> wrote:

> On 11/4/16 6:30 AM, Clark Wang wrote:
> > For example, if I have inputted the following after the prompt:
> >
> > # foo "abc"
> >
> > In bash 4.3's vi-insert mode, when I press ctrl-w it'll delete the whole
> > "abc" (including quotes). But with 4.4 I have to press ctrl-w for 3 times
> > (one for the right " char, one for abc and one for the left " char).
>
> This was changed due to a bug report about readline not being Posix-
> conformat with its ^W binding in vi insert mode.  Posix specifies that
> word boundaries include whitespace and punctuation.  Apparently vi is
> the same, but I'm not enough of a vi user to say.
>

> The old binding (unix-word-rubout) is still there, but to avoid it being
> overwritten, you need to set the readline variable `bind-tty-special-chars'
> to `off'.  (Since ^W is your default stty werase character, readline will
> bind it to its vi-mode equivalent when that variable is enabled.)
>

This works great. Thanks Chet.

>
> You would have noticed the ^W binding being overwritten if you had done
> a `bind -m vi-insert -p' after one of your key binding commands, but I
> suppose there isn't any real reason to do that.
>
> Chet
> --
> ``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/
>

bind -m vi-insert '"jj": "\e"' problem in 4.4

[Clark Wang]

For example, in vi-insert mode I input following in the command line:

# foo abc

The cursor is right after 'c'. Now if I press ESC then it'll go to
vi-command mode and the cursor will move to under 'c'. But if I press jj
the cursor would be still after 'c' and if then I press h the cursor will
skip 'c' and move to under 'b' . In 4.3, ESC and jj works the same so there
must be something changed in 4.4. Please take a look.

-clark

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

Re: why is 'direxpand' converting relative paths to absolute?

[Clark Wang]

On Mon, Aug 17, 2015 at 5:54 AM, Linda Walsh b...@tlinx.org wrote:

 From the manpage I wouldn't have guess it changed
 paths to absolute -- but would expand variables and wildcards
 in the path.

 It doesn't seem to make alot of sense when there are other
 ways to go from rel-abs, but not so many that just expand
 vars or aliases on a dir.
 Does anyone know why path conversion was built into it?


I had the same problem months ago. See Chet's answer:
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00069.html

-clark




 Linda Walsh wrote:



 Andreas Schwab wrote:

 Linda Walsh b...@tlinx.org writes:

 in bash 4.3.39,
 if I type a command, (like .(source)) and a relative path
 like : ../confcomplete,
 it expands the relative pathname to absolute pathnames.


 Worksforme.  Make sure to run complete -r first.

 ---
 You didn't say what version of bash you were using... but
 that may not be relative:

 It seems to be direxpand -- do you have it on or off.

 It is supposed to perform word expansion.  It doesn't
 say it will convert relative paths to absolute.

 Has it always been that way? (I thought direxpand expanded
 variables in a path?)

Re: definite way to determine the running shell

[Clark Wang]

On Fri, Mar 27, 2015 at 11:36 AM, Christoph Anton Mitterer 
cales...@scientia.net wrote:

 Hey.

 There are a lot of articles on the web about detecting the actually
 running shell.
 Unfortunately, just relying on $SHELL doesn't really work since when I
 invoke e.g. csh from bash, it would be still $SHELL=bash and I guess I
 won't be able to convince all shell upstreams to overwrite $SHELL (which
 IMHO would be much better, and more like $TERM).

 Now I see basically two other ways to detect a shell:
 a) using ps or something similar... which is not really portable either
 and can be rather easily/accidentally fooled

 b) Using some env vars typically to the shell, e.g. BASH_VERSION for
 bash.
 AFAIU per default these are not declared'ed -x , so when I rund fooShell
 from bash it wouldn't be inherited.
 But the user could still manually mark it exportable.

 c) I've also thought about somehow using e.g. shopt, when it runs I
 could be sure, it was bash. But for that in turn I'd need to make sure
 whether it's a built-in command, which works in bash with the builtin
 built in command ;) ... but not portably as in POSIX shell command
 language (at least not that I'd know).


 Is there some better way to do this (at least to detect bash)? E.g. some
 VAR that bash sets and that it would neither take from its own
 environment when being started nor that it would pass on to processes?


For bash I think you can just check $BASH_VERSION.

Also see Sven Mascheck's whatshell:
http://www.in-ulm.de/~mascheck/various/whatshell/ .

-clark


 Thanks,
 Chris.

Re: BASH_ARGV -- arguments are reversed

[Clark Wang]

On Fri, Nov 28, 2014 at 1:07 PM, William Park opengeome...@yahoo.ca wrote:

 Hi all,

 I just noticed that BASH_ARGV contains commandline arguments in reverse.


That's because it's a stack. According the bash manual: The final
parameter of the last subroutine call is at the top of the stack; the first
parameter of the initial call is at the bottom.


 $ cat  x.sh
 #!/bin/sh
 declare -p BASH_ARGV
 ^D

 $ sh x.sh 1 2 3 4 5
 declare -a BASH_ARGV='([0]=5 [1]=4 [2]=3 [3]=2 [4]=1)'
 --
 William

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

[Clark Wang]

On Mon, Sep 8, 2014 at 1:07 AM, Chet Ramey chet.ra...@case.edu 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 `@TAB' 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-TABTAB
  @host-a.us  @host-b.us
  $ foo @host-aTAB
  $ 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 @localhostTABTAB
  @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/

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: `complete -d cd' does not work for dirs with a ' char

[Clark Wang]

On Sat, Apr 26, 2014 at 3:41 AM, Chet Ramey chet.ra...@case.edu 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 TAB
  [STEP 103] $ cd foo\'s\ dir/TAB
 
  The 1st TAB 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/

`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 TAB
[STEP 103] $ cd foo\'s\ dir/TAB

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

-clark

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-TAB
[STEP 104] $ foo the-dir/TAB
[STEP 104] $ foo the-dir/file
bash: foo: command not found
[STEP 105] $ foo the\SPACETAB
[STEP 105] $ foo the\ dir/TAB
[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

Re: direxpand in 4.3 is different from in 4.2

[Clark Wang]

On Sat, Mar 15, 2014 at 12:06 AM, Chet Ramey chet.ra...@case.edu wrote:

 On 3/14/14 2:39 AM, Clark Wang wrote:
  For example in 4.3 when direxpand is enabled, `cd ./tmpTAB' 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/

direxpand in 4.3 is different from in 4.2

[Clark Wang]

For example in 4.3 when direxpand is enabled, `cd ./tmpTAB' 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: flag for quiet CDPATH

[Clark WANG]

On Tue, Jan 21, 2014 at 8:16 AM, Elliott Forney elliott.for...@gmail.comwrote:

 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

Re: backward-line

[Clark WANG]

On Mon, Jan 28, 2013 at 3:07 PM, Egmont Koblinger egm...@gmail.com 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: Q on Bash's self-documented POSIX compliance...

[Clark WANG]

On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh b...@tlinx.org 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: Hitting Esc twice auto-completes

[Clark WANG]

On Wed, Nov 21, 2012 at 6:40 AM, smu johnson smujohn...@gmail.com 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 smujohn...@gmail.com

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

[Clark WANG]

On Tue, Sep 4, 2012 at 7:13 PM, Roman Rakus rra...@redhat.com 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

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 Up arrow key.

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:

Re: bash build

[Clark WANG]

On Sat, Jun 2, 2012 at 7:39 AM, rac8006 rac8...@aol.com 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 wb8...@qsl.net 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/TAB
 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: Passing variables by reference conflicts with local

[Clark Wang]

On Fri, Apr 27, 2012 at 02:02, Bill Gradwohl b...@ycc.com 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 wool...@eeg.ccf.org 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: Severe Bash Bug with Arrays

[Clark Wang]

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)