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

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

Re: Bash-5.3-alpha available

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

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

(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

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

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

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

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

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

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)

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

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

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

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?

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

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

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

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 >

Re: is it a bug

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

Re: possible bugs with colored-stats

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

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

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

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

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 th

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

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

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`

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

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

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

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

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

Re: Forgets color when resizing with newline in prompt

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

Re: Where is GLOBAL_COMMAND?

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

bash5: "progcomp_alias" and "complete -D"

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

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

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

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?

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

Re: Variables can’t contain NUL

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

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

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

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

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?

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

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

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

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

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

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

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

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.

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

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,

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

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

Re: coding standards

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,

Re: coding standards

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

Re: coding standards

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

Re: misleading error message from variable modifier

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:

Re: Unset array doesn't work

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,

Re: misleading error message from variable modifier

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

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

Re: Unset array doesn't work

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

Re: Quoting and string comparison

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;

Re: Feature request: PROMPT_COMMANDS array variable

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

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

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 1

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

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

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

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

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

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 >

Claim `declare' as a special command in manual?

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]

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

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 c

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

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

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

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

Re: Documentation issue

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

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

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

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

Re: Documentation issue

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

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

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

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

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,

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

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

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

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

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

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 accep

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

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

A background ssh can take over the tty from bash?

(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

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

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

Re: Strange bash behavior

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

Re: Strange bash behavior

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

Re: Strange bash behavior

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

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

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 -N n'' removes leading "\n"s

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

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

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

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 mov

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

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

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

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

Re: Bash bug

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

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

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

Re: definite way to determine the running shell

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

Re: BASH_ARGV -- arguments are reversed

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

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

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

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

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

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

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

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?

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

Re: direxpand in 4.3 is different from in 4.2

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

direxpand in 4.3 is different from in 4.2

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

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

Re: backward-line

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

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

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

Re: Hitting Esc twice auto-completes

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

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

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

Bug with `eval return' in .bashrc ?

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

Re: regex in bashexpression doesn't work

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

Re: bash build

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

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

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

Re: Passing variables by reference conflicts with local

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

Re: Passing variables by reference conflicts with local

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

Re: Severe Bash Bug with Arrays

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'

  1   2   >