Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

Date:Fri, 25 Apr 2025 15:44:47 -0400 From:Chet Ramey Message-ID: <9d1a2482-d47f-4c49-9581-45c5db81d...@case.edu> | I can't reproduce this using bash-5.2.37. I can. | I suspect this is the result your | programmable completion specification for `cat' produces.

Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

Thanks, I'll check it out. On Sat, 26 Apr 2025, 1:14 am Chet Ramey, wrote: > On 4/25/25 11:18 AM, Tanmay Jagtap wrote: > > *Dear Bash Maintainers,* > > > > I have encountered an issue with Bash autocompletion on my system. > > Specifically, a file beginning with three dots (e.g., ...Hiding-From-

Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

On 4/25/25 11:18 AM, Tanmay Jagtap wrote: *Dear Bash Maintainers,* I have encountered an issue with Bash autocompletion on my system. Specifically, a file beginning with three dots (e.g., ...Hiding-From-You) is autocompleted even when no dot (.) has been typed, which seems inconsistent with typi

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sun, 9 Feb 2025 08:52:07 -0500 From:Greg Wooledge Message-ID: <20250209135207.gn29...@wooledge.org> | Oh, that must be another 2024 change. As my earlier correction indicated, it didn't happen. It turns out that all the *ash shells (bash, yash, and all derive

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 12:30:33 +0700, Robert Elz wrote: > | and "read -p" for the prompt. > > which could be just a printf without a trailing \n before the > read -- but doesn't need to be as read -p is in the standard. Oh, that must be another 2024 change. The manpages-posix package I've go

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sun, 09 Feb 2025 12:30:33 +0700 From:Robert Elz Message-ID: <16760.1739079...@jacaranda.noi.kre.to> | read -- but doesn't need to be as read -p is in the standard. I was sure that had been added, but as usual when I am relying on memory I was wrong, -p isn't i

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sat, 8 Feb 2025 19:33:10 -0500 From:Greg Wooledge Message-ID: <20250209003310.gm29...@wooledge.org> | You really want bash's ${var//search/replace} feature for the | renaming step, In some cases I might agree, not necessarily about the mechanism, but about d

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 06:35:38 +0700, Robert Elz wrote: > ps: there is almost never a good excuse to use non-standard sh > extensions (bash's, or any other shells), when writing a standard > conforming script would allow any Bourne shell variant to > work, and that's certainly the case here, and

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sat, 8 Feb 2025 12:08:10 -0500 From:Greg Wooledge Message-ID: <20250208170810.gl29...@wooledge.org> | OK, I think you have something like this: | | while read -r f; do | if [[ $f = *[[:space:]]* ]]; then | read -r -p "Fix <$f>? " yn |

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On 2/8/25 10:48 AM, carlyle_moul...@optusnet.com.au wrote: Then follows a while read REPLY; do # loop to read records from /tmp/$USER/tempfile1 # The first record is discarded, from the remainder the File_Name is extracted and passed to a functionas a quoted string to function File_Contains_Blan

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 02:48:42 +1100, carlyle_moul...@optusnet.com.au wrote: > I have a script to go through file names in the current directory, > check whether they contain blanks and optionally replace blanks with > underscores. for f in *[[:space:]]*; do read -r -p "Fix <$f>? " yn if

Re: bug in bash

On 5/14/24 11:12 AM, Chet Ramey wrote: On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to

Re: bug in bash

On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to kill a procsub when you interrupt the j

Re: bug in bash

On Mai 14 2024, Chet Ramey wrote: > Setting the process group might solve this particular issue, at the cost of > losing keyboard-generated signals. That's not so bad for SIGINT, though > people do expect to be able to kill a procsub when you interrupt the job > using it, but you also wouldn't be

Re: bug in bash

On 5/13/24 3:37 PM, Oğuz wrote: On Monday, May 13, 2024, Chet Ramey > wrote: performs the setpgid in the process forked to run the process substitution). Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout

Re: bug in bash

On Monday, May 13, 2024, Chet Ramey wrote: > performs the setpgid in the process forked > to run the process substitution). > Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout? Direct it from /dev/null? -- Oğuz

Re: bug in bash

On 5/12/24 10:00 AM, Oğuz wrote: On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: Since the redirection fails and the cat command is never started, bash doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553 execve("/usr/bin/w

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > Ah... I assumed bk was an existing file. > > hobbit:~$ cat <(wc -l) <.bashrc > wc: 'standard input': Input/output error > 0 > hobbit:~$ Even then there can be a race when the foreground command finishes fast enough that bash switches the terminal process gr

Re: bug in bash

On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: > Since the redirection fails and the cat command is never started, bash > doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553 execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10

Re: bug in bash

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote: > > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > >> I found a bug when i tried with syntax <(cmd). this is an example > >> cat <(wc -l) < bk > Since the redirection fails and the cat command is never started, bash >

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: >> I found a bug when i tried with syntax <(cmd). this is an example >> cat <(wc -l) < bk > > What is "wc -l" supposed to read from? It counts lines of standard input, > until EOF is reached. But

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk What is "wc -l" supposed to read from? It counts lines of standard input, until EOF is reached. But its standard input is a terminal. And you're r

Re: bug in bash

On Sun, 12 May 2024 03:55:21 +0200 Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside in the parenthesis and the main process

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside in the parenthesis and the main pro

Re: Bug in Bash on syntax error in functions?

Understood. Thank you both. On Sat, Apr 9, 2022 at 6:46 AM Chet Ramey wrote: > On 4/8/22 4:33 PM, Lawrence Velázquez wrote: > > > Notably, these don't execute "echo b" either, demonstrating that > > this isn't actually about functions at all. > > I may have been too obscure saying the function b

Re: Bug in Bash on syntax error in functions?

On 4/8/22 4:33 PM, Lawrence Velázquez wrote: Notably, these don't execute "echo b" either, demonstrating that this isn't actually about functions at all. I may have been too obscure saying the function body was a brace group command. { echo a echo "$[ 1 + ]"

Re: Bug in Bash on syntax error in functions?

On Fri, Apr 8, 2022, at 3:23 PM, Chet Ramey wrote: > So the difference is between a command not found > >> $ ./testfail1 >> a >> ./testfail1: line 3: fail_command: command not found >> b >> $ ./testfail2 >> a >> ./testfail2: line 3: 1 + : syntax error: operand expected (error token is >> "+ ") >> b

Re: Bug in Bash on syntax error in functions?

On 4/8/22 2:42 AM, Roel Van de Paar via Bug reports for the GNU Bourne Again SHell wrote: Hi! I am using GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu). Here is what looks to be a bug: It's not. There are a couple of misconceptions here. Let's go through them.

Re: Bug in Bash Version 5.0.11(1)-release

On Mon, 14 Oct 2019 14:29:39 -0400 Greg Wooledge wrote: > On Mon, Oct 14, 2019 at 06:21:23PM +, Daniel Hannon wrote: > > I am running Arch Linux > > > > Locale is as follows > > > > locale: Cannot set LC_CTYPE to default locale: No such file or directory > > locale: Cannot set LC_MESSAGES t

Re: Bug in Bash Version 5.0.11(1)-release

in which it is replicated > > From: Greg Wooledge > Sent: Monday 14 October 2019 13:53 > To: Daniel Hannon > Cc: bug-bash@gnu.org > Subject: Re: Bug in Bash Version 5.0.11(1)-release > > On Mon, Oct 14, 2019 at 10:39:41AM +, Da

Re: Bug in Bash Version 5.0.11(1)-release

On Mon, Oct 14, 2019 at 10:39:41AM +, Daniel Hannon wrote: > the use of the "…" character results in the ability to delete the bash prompt > string using backspace I can't reproduce this. wooledg:~$ bash wooledg:~$ PS1='…\h:\w\$ ' …wooledg:~$ echo "$BASH_VERSION" 5.0.3(1)-release …wooledg:~$

Re: Bug in Bash 4.4 Return history of commands

On 12/12/16 12:26 PM, Arion Deno wrote: > I believe the bug should have already been fixed .. but It's not a bug. > A description of the bug behaviour. : > > When you type the command: history -c, to clear the bash history, > typing bash -v appears to open all configuration files, and the > comm

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 11/11/15 6:16 PM, Keith Thompson wrote: > Yeah, that's fine. I will modify bash to set the original signal > dispositions to SIG_DFL in interactive shells. > > > Does that mean reverting default_tty_job_signals() in jobs.h to the > version in bash 4.3.30: > > set_signal_handler (

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Wed, Nov 11, 2015 at 3:16 PM, Keith Thompson wrote: > On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey wrote: > >> On 11/10/15 10:03 PM, Keith Thompson wrote: >> > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson < >> keithsthomp...@gmail.com >> > > wrote: >> > >>

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey wrote: > On 11/10/15 10:03 PM, Keith Thompson wrote: > > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson < > keithsthomp...@gmail.com > > > wrote: > > > > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab < > sch...@l

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 11/10/15 10:03 PM, Keith Thompson wrote: > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson > wrote: > > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab > wrote: > > Chet Ramey mailto:chet.ra...@case.edu>> writes:

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

Keith Thompson writes: > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab > wrote: > >> Chet Ramey writes: >> >> > I can make bash blow away the original signal dispositions and pretend >> they >> > were SIG_DFL when an interactive shell starts, if there is no >> alternative. >> >> Given that lo

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson wrote: > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab > wrote: > >> Chet Ramey writes: >> >> > I can make bash blow away the original signal dispositions and pretend >> they >> > were SIG_DFL when an interactive shell starts, if there is no >>

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab wrote: > Chet Ramey writes: > > > I can make bash blow away the original signal dispositions and pretend > they > > were SIG_DFL when an interactive shell starts, if there is no > alternative. > > Given that login(1) has the same behaviour there is

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

Chet Ramey writes: > I can make bash blow away the original signal dispositions and pretend they > were SIG_DFL when an interactive shell starts, if there is no alternative. Given that login(1) has the same behaviour there is probably no alternative. Andreas. -- Andreas Schwab, sch...@linux-m

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey wrote: > On 11/10/15 3:17 PM, Keith Thompson wrote: > > On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey > > wrote: > > > > > > > > It seems like you need to figure out why rxvt starts the shell with > > SIGTSTP ignored

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 11/10/15 3:17 PM, Keith Thompson wrote: > On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey > wrote: > > > > It seems like you need to figure out why rxvt starts the shell with > SIGTSTP ignored. It doesn't seem like anything that the system /bin/sh > or t

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey wrote: > > > It seems like you need to figure out why rxvt starts the shell with > SIGTSTP ignored. It doesn't seem like anything that the system /bin/sh > or the bash version you're running does, since xterm doesn't exhibit > this behavior. > > The d

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 11/10/15 2:15 PM, Keith Thompson wrote: > But there's still a mystery here. Why does it behave differently under rxvt > vs. xterm, > and why does that difference show up in bash 4.4-beta but not in 4.3.30? > (Both versions of bash are built from source on the same system.) > > Running bash 4.3.

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

But there's still a mystery here. Why does it behave differently under rxvt vs. xterm, and why does that difference show up in bash 4.4-beta but not in 4.3.30? (Both versions of bash are built from source on the same system.) Running bash 4.3.30 under either xterm 261 or rxvt v2.6.4, I get: bash-

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 11/9/15 5:55 PM, Keith Thompson wrote: > I have some more information on this. In the latest test, > the problem occurs when I run bash under rxvt, but not when I run it under > xterm. > > Using strace, I've found a difference in a call to rt_sigaction(). It calls > > rt_sigaction(SIGTSTP, {

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

I have some more information on this. In the latest test, the problem occurs when I run bash under rxvt, but not when I run it under xterm. Using strace, I've found a difference in a call to rt_sigaction(). It calls rt_sigaction(SIGTSTP, {SIG_DFL, ...}) under xterm (which works correctly), but

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

$ trap trap -- 'show_error' ERR $ type show_error show_error is a function show_error () { printf "\e[1mExit $?\e[m\n" 1>&2 } $ On Sat, Oct 31, 2015 at 12:00 AM, Andreas Schwab wrote: > Keith Thompson writes: > > > For a while, I had two running login shells, one that had the problem > > a

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

Keith Thompson writes: > For a while, I had two running login shells, one that had the problem > and one that didn't. Comparing the output of "set" and "shopt" from > both shells didn't show any differences that could explain this. What's the output of trap? Andreas. -- Andreas Schwab, sch..

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

Whatever the problem is, it seems to be subtle. I can't *reliably* reproduce it on the original Debian 6 system. I saw the problem in a shell that had been running for a couple of weeks, with several thousand commands executed. Replacing the shell process with "exec bash -l" (using the same versio

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

I just tried it on a two VMs running Debian 6 and 7, respectively. The problem did not occur. It also doesn't occur on the original Debian 6 system if I run it as "bash --norc". (Sorry, I should have tried that in the first place.) So the problem has something to do with my own setup scripts. I'l

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

Sorry, I meant to save one of the messages in this thread so I could reply with the proper message ID, but I accidentally deleted them all. And the web-based archive doesn't report message IDs. I cannot reproduce the reported problem on Debian 6. All looks normal for me. arc1:/var/tmp/bash-4.4-b

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

On 10/28/15 10:02 PM, Keith Thompson wrote: > I'm running bash 4.4-beta, built from bash-4.4-beta.tar.gz, on two > different x86_64 systems, one running Debian 6.0.10 and another running > Linux Mint 17.3. > > On both systems, if I run "man rm" (for example) I can read the "rm(1)" > man page using

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

"stty -a" on both systems prints: speed 38400 baud; rows 57; columns 237; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cs

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

what does `stty -a` show on the two systems ? what version of readline are you using on both ? -mike signature.asc Description: Digital signature

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

I've found another symptom of the problem. It has something to do with the handling of the TSTP signal (normally sent by typing Ctrl-Z). Running bash 4.4-beta, I type the "cat" command. While "cat" is running, I type Ctrl-Z. Normally this should suspend the "cat" process and give me a shell promp

Re: Bug in bash 4.3.30 with --disable-job-control

> There is a bug of some sort in bash 4.3.30 (and likely others) when > compiled with --disable-job-control on Linux/x86_64. > > The following script will produce output after running for about 30 seconds: > while true; do dfOutput="$(/bin/echo test)"; if echo "${dfOutput}" | > /bin/

Re: Bug in bash 4.3.30 with --disable-job-control

On 6/10/15 12:55 PM, Eduardo A. Bustamante López wrote: > Notice that it doesn't happen if you don't use the interactive mode. Thanks. This might be the key. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS

Re: Bug in bash 4.3.30 with --disable-job-control

On Wed, Jun 10, 2015 at 11:00:51AM -0400, Chet Ramey wrote: > On 6/2/15 1:07 PM, Roy Keene wrote: > > All, > > > > There is a bug of some sort in bash 4.3.30 (and likely others) when > > compiled with --disable-job-control on Linux/x86_64. > > I can't reproduce this on RHEL 6 or Fedora 22 wit

Re: Bug in bash 4.3.30 with --disable-job-control

On 6/2/15 1:07 PM, Roy Keene wrote: > All, > > There is a bug of some sort in bash 4.3.30 (and likely others) when > compiled with --disable-job-control on Linux/x86_64. I can't reproduce this on RHEL 6 or Fedora 22 with bash-4.3.39. -- ``The lyf so short, the craft so long to lerne.'' - Ch

Re: Bug in bash 4.3.30 with --disable-job-control

On 6/2/15 1:07 PM, Roy Keene wrote: > All, > > There is a bug of some sort in bash 4.3.30 (and likely others) when > compiled with --disable-job-control on Linux/x86_64. I will have to look at this on a Linux system when I get access to one. It doesn't misbehave when I run it on Mac OS X. Ch

Re: Bug in bash(1)

On 8/21/13 1:21 PM, Thomas Hood wrote: > There appears to be a redundancy in the description of the "disown" > builtin in bash(1). Version is 4.2. Thanks for the report and patch. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - H

Re: Bug? in bash setlocale implementation

On 02/22/2012 01:52 AM, Chet Ramey wrote: > On 2/21/12 3:51 AM, John Kearney wrote: > >> Bash Version: 4.2 Patch Level: 10 Release Status: release >> >> Description: Basically if setting the locale fails variable >> should not be changed. > > I disagree. The assignment was performed correctly a

Re: Bug? in bash setlocale implementation

On 2/21/12 3:51 AM, John Kearney wrote: > Bash Version: 4.2 > Patch Level: 10 > Release Status: release > > Description: > Basically if setting the locale fails variable should not be changed. I disagree. The assignment was performed correctly and as the user specified. The fact that a side

Re: Bug in bash regex: doesn't recognise the line start caret

On Fri, Nov 4, 2011 at 4:31 AM, Graham North wrote: > Hi, > > There seems to be a bug in bash regex. > > It doesn't recognise the line start caret: > > --Commands: > ONE="/fred" > TWO="fred/" > REGEX='^/' > echo "$ONE $TWO $REGEX" > [[ "$ONE" =~ "$REGEX" ]] && echo yes || echo no > [[ "$TWO" =~ "$

Re: Bug in Bash-3.00

On Tue, Nov 15, 2005 at 11:04:54AM +0100, Ivano Primi wrote: > The bug which I will describe > affects the version 3.00 of bash shipped > with Slackware GNU/Linux 10.2 . > This version has been obtained by applying > all the patches available at your site (from > bash30-001 to bash30-016) > plus an

Re: bug in bash handling of PS1 prompt

On Wed, Jun 22, 2005 at 03:21:46PM -0700, [EMAIL PROTECTED] wrote: > When assigning to PS1 to change the prompt, bash > appears to append any new value to the initial default > value, rather than to replace it. I expect you have PROMPT_COMMAND set. Tim. */ pgpZD44ZaRlI8.pgp Description: PGP si