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

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

*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 typical Bash behavior where hidden files are exc

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

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

From: carl To: bug-bash@gnu.org Subject: [50 character or so descriptive subject here (for reference)] In a script two instances of the read builtin mutually interfere Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS:

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

will show "wc: > stdin: read: Input/output error". Or we can ctrl C. Sounds appropriate. What's the "bug in bash" supposed to be? What did you think this command would do?

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

bug in bash

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 do < bk. They work parallel. Because of that, yeah. At least, I tried

Re: maybe a bug in bash?

On 2023-06-30 at 15:49 +0200, Sebastian Luhnburg wrote: > First, in my LPIC-1 course the lecturer tell me it is better (not > binding) to deny SSH login for root users (especially for the user with > the name root). The reason is simple: decrease the attack surface. Yes, > a secure password need

Re: maybe a bug in bash?

On Sat, Jul 1, 2023, 15:37 Greg Wooledge wrote: > On Sat, Jul 01, 2023 at 02:45:16PM +0200, alex xmb ratchev wrote: > > declare -p > > works well for transmitting bash vars around via ssh > > > > ssh foo "$(declare -p vars) > > more code" > > I haven't tested that thoroughly, but it looks OK. Ho

Re: maybe a bug in bash?

On Sat, Jul 01, 2023 at 02:45:16PM +0200, alex xmb ratchev wrote: > declare -p > works well for transmitting bash vars around via ssh > > ssh foo "$(declare -p vars) > more code" I haven't tested that thoroughly, but it looks OK. However, it doesn't address the problem in this thread, which is t

Re: maybe a bug in bash?

On Fri, Jun 30, 2023, 23:21 Greg Wooledge wrote: > On Sat, Jul 01, 2023 at 05:47:33AM +0900, Dominique Martinet wrote: > > hm, this has the password show up in ps on the box executing ssh; > > depending on the context that can be bad. > > Fair enough. We have no way to judge the OP's risk analys

Re: maybe a bug in bash?

On Sat, Jul 01, 2023 at 05:47:33AM +0900, Dominique Martinet wrote: > hm, this has the password show up in ps on the box executing ssh; > depending on the context that can be bad. Fair enough. We have no way to judge the OP's risk analysis, because they've kept almost everything secret so far. I

Re: maybe a bug in bash?

Greg Wooledge wrote on Fri, Jun 30, 2023 at 10:36:36AM -0400: > > then as Greg suggested pass password to bash as argument instead; > > assuming password has been quoted once as previously: > > ssh user@machine << EOF > > bash -c 'echo \$1' -- $password > > EOF > > I never suggested embedding the

Re: maybe a bug in bash?

On Fri, Jun 30, 2023 at 11:17:06PM +0900, Dominique Martinet wrote: > Sebastian Luhnburg wrote on Fri, Jun 30, 2023 at 03:47:57PM +0200: > > p.s.: in the final script, it is only one SSH: > > > > ssh user@machine << EOF > > /bin/bash -c "do something with the password" > > EOF I wish you would re

Re: maybe a bug in bash?

Sebastian Luhnburg wrote on Fri, Jun 30, 2023 at 03:47:57PM +0200: > /bin/bash -c "echo 'password in subshell in here document: ' ${password@Q}" ${password@Q} is still within double quotes in your here-document here; these quotes are breaking the escaping you used. This would be out of quotes: ba

Re: maybe a bug in bash?

On Fri, Jun 30, 2023 at 03:49:23PM +0200, Sebastian Luhnburg wrote: > You suggest to use an argument, to pass the password. Please correct me if I > be wrong, but to write one or more password(s) in clear text as an argument > in the terminal (./myscript.sh password1 password2) is not the best prac

Re: maybe a bug in bash?

Hello Greg, thank you for your quick answer, too! First, I am not a Bash mastermind or have deeper knowledge about secure programming. Your suggestion about the risk of coding injection is very interesting! But I will read the full text after my holidays, which will begin after this E-Mail :)

Re: maybe a bug in bash?

Thank you very much for your quick answer! I am not sure what do you mean with "open the quote"? I try to copy your example, but my copy did not work. I wrote this: #!/usr/bin/env bash initial_password='$abc&xyz' echo "initial password: " $initial_password among_password="${initial_password@Q

Re: maybe a bug in bash?

On Thu, 29 Jun 2023 at 23:42, Greg Wooledge wrote: > The answer to this is [...] just ssh in as root instead of nonroot + sudo. > > Some folks will scream that this is a bad idea, horrible practice, can't > do it, etc. These folks are idiots. Ssh can be configured to allow root > logins only w

Re: maybe a bug in bash?

On Thu, 29 Jun 2023 11:55:12 +0200 Sebastian Luhnburg wrote: > #!/usr/bin/env bash > > initial_password="\$abc&xyz" > echo "initial password: " $initial_password > printf -v password '%q' $initial_password > echo "initial password with escaped characters: " $password > bash << EOF > echo "passwo

Re: maybe a bug in bash?

On Thu, Jun 29, 2023 at 11:33:15AM +0200, Sebastian Luhnburg wrote: > I want to use this password in an here document, which inject some > commands into a SSH-Connection (for simplification, I use the bash instead > of ssh in the test script below). Skipping the "is it a bug or not" part, which ha

maybe a bug in bash?

Hello, I'm not sure, if I found a bug or if I miss some understanding, but I want to report it, if it is a bug. Please tell me more, if I'm right or if it is my mistake. I have a script, in which I have an password (I get it from a password manager - no excitement ;D ). The password begin wi

Re: maybe a bug in bash?

Sebastian Luhnburg wrote on Thu, Jun 29, 2023 at 11:55:12AM +0200: > initial_password="\$abc&xyz" > echo "initial password: " $initial_password > printf -v password '%q' $initial_password > echo "initial password with escaped characters: " $password > bash << EOF > echo "password in here document:

maybe a bug in bash?

Hello, I'm sending this mail a past minutes ago, but I was not a member of this mailing list. The mail was not listed in the archive, so I send it again, with membership of the mailing list. I hope I don't sending it twice to you. I'm not sure, if I found a bug or if I miss some understandi

Re: Possible bug in bash

Greg Wooledge writes: > On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: >> Reading your message, I believe that the rule can be stated as follows, >> and I'd thank you to check it: && and || have the same precedence, and >> they both "associate left". So for example >> x && y

Re: 回复: Possible bug in bash

On 1/17/23 2:21 AM, anonymous4feedb...@outlook.com wrote: I am sorry I made a mistake in the first email. Bash printed foo= bar=v and all other shells printed foo=v bar=. It turns out I am using --posix to enable alias in bash, and that’s what makes the difference. Thanks for the update; I fix

回复: Possible bug in bash

ug-bash@gnu.org> 抄送: chet.ra...@case.edu<mailto:chet.ra...@case.edu> 主题: Re: Possible bug in bash On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote: > For the follow script > alias al=' ' > alias foo=bar > al for foo in v > do echo foo=$foo bar=$bar > done &g

Re: Possible bug in bash

On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote: For the follow script alias al=' ' alias foo=bar al for foo in v do echo foo=$foo bar=$bar done bash (version 5.1.16) prints foo=v bar=, while all other shells I tested (dash, ksh, zsh, and yash) all prints foo= bar=v. That's strange. I

Possible bug in bash

For the follow script alias al=' ' alias foo=bar al for foo in v do echo foo=$foo bar=$bar done bash (version 5.1.16) prints foo=v bar=, while all other shells I tested (dash, ksh, zsh, and yash) all prints foo= bar=v. Apparently bash substitutes foo for bar in line 3 because the previous alias al

Re: Possible bug in bash

On 5/13/22 10:36 PM, Dale R. Worley wrote: Robert Elz writes: Note particularly that there is no operator precedence between && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and |

Re: Possible bug in bash

Date:Fri, 13 May 2022 23:27:50 -0400 From:Greg Wooledge Message-ID: | Not really. What's the difference? | Let's say you have a bunch of commands strung together like this: | | a && b || c && d || e && f || g | | We start with the shell's command parser

Re: Possible bug in bash

Date:Fri, 13 May 2022 22:36:56 -0400 From:"Dale R. Worley" Message-ID: <87ilq8hmbb@hobgoblin.ariadne.com> | Reading your message, I believe that the rule can be stated as follows, | and I'd thank you to check it: OK | && and || have the same precedence, an

Re: Possible bug in bash

On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: > Reading your message, I believe that the rule can be stated as follows, > and I'd thank you to check it: && and || have the same precedence, and > they both "associate left". So for example > x && yy || zz > is equivalent (as a

Re: Possible bug in bash

Robert Elz writes: > Note particularly that there is no operator precedence between > && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and || have the same precedence, and they both "

Re: Possible bug in bash

> > Have a thorough look around at: > http://mywiki.wooledge.org/BashPitfalls > http://mywiki.wooledge.org/BashFAQ > http://mywiki.wooledge.org/BashGuide > > and you will find a lot of useful knowledge that is > explained with considerable effort by many people. Pity I didn't find this page when

Re: Possible bug in bash

On Fri, 13 May 2022 at 18:18, flyingrhino wrote: > Before opening the bug I looked online for if-then-else vs [[ and no > proper information was available, definitely not to the extent you explain > here. Have a look here: http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3 >

Re: Possible bug in bash

Thanks Lawrence for the response. Between you and Robert I now have a clear understanding on this and I'll go back and fix the bug in my code which used this construct. Ken. On Fri, 13 May 2022 00:51:49 -0400 Lawrence Velázquez wrote: > On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote: >

Re: Possible bug in bash

Hi, Thank you very much for the detailed description of this scenario. Before opening the bug I looked online for if-then-else vs [[ and no proper information was available, definitely not to the extent you explain here. This is very useful and rare knowledge and the effort you took to explain t

Re: Possible bug in bash

Not a bug. Do not use && || as if they were a replacement for if then else fi they aren't. In some simple cases it all works out OK, but not in general, as you discovered. If you mean if x; then y; else z; fi then write that, not x && y || z The way and-or lists work, is that the first command

Re: Possible bug in bash

On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote: > Should the "else" condition after the: || run if the last command in > the: && section exits non zero? Yes. This behavior is not a bug; ''A && B || C'' is simply not equivalent to ''if A then B; else C; fi''. https://mywiki.wooledge.or

Possible bug in bash

Hi, Should the "else" condition after the: || run if the last command in the: && section exits non zero? I tested it this way: Script: #!/bin/bash [[ "a" == "a" ]] && \ { echo "equal" ls x } || { echo "* SHOULD NOT DISPLAY 4" } Result: ./moo.sh equal ls:

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.

Bug in Bash on syntax error in functions?

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: -- $ cat testfail1 #!/bin/bash echo 'a' fail_command echo 'b' $ cat testfail2 #!/bin/bash echo 'a' ech

Re: possible bug in Bash 5.0

uot; \> "$b" ]; then >   echo "single-bracket" > fi > if [[ "$a" > "$b" ]]; then >   echo "double-bracket" > fi > > According to some web pages I was expecting that single-bracket and > double-bracket should give same

possible bug in Bash 5.0

uot;$a" > "$b" ]]; then echo "double-bracket" fi According to some web pages I was expecting that single-bracket and double-bracket should give same result. I'm not a Bash-expert, therefore I'm not sure whether this is a real bug in Bash 5.0. Merry Christ

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

Bug in Bash Version 5.0.11(1)-release

the use of the "…" character results in the ability to delete the bash prompt string using backspace

Re: Possible bug in bash... or maybe UFU?

On 6/4/19 3:09 AM, George R Goffe wrote: > Hi, > I'm trying to build the latest bash from ftp.gnu.org and am having some > problems. Are these a bug or am I doing something wrong? This is what happens when the bash configure can't find a working termcap or curses library. What does the Makefile h

Re: Possible bug in Bash Reference Manual - lists of commands

On Wed, May 22, 2019 at 02:38:29PM +0800, Ralph Jensen wrote: > The Bash Reference Manual, Edition 5 and earlier versions define lists of > commands as follows: > > "A list is a sequence of one or more pipelines separated by one of the > operators ..." (Bash Reference Manual 3.2.3). > > Shouldn't

Possible bug in Bash Reference Manual - lists of commands

The Bash Reference Manual, Edition 5 and earlier versions define lists of commands as follows: "A list is a sequence of one or more pipelines separated by one of the operators ..." (Bash Reference Manual 3.2.3). Shouldn't that say commands rather than pipelines? Ralph Jensen

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

Bug in Bash 4.4 Return history of commands

I believe the bug should have already been fixed .. but The version number of Bash: GNU Bash 4.4 --- Hardware and OS: Intel pentium 2 300 MHZ 256 MB Ram VGA: Nvidia MX 4000 - 64 mb Gnu/ Linux Debian 8.6.0 - i586 , LXDE - The compiler used to compile Bash: Gcc 4.9.2 -

Re: Question: is this a bug in BASh (pre-exec trap)

On 9/9/16 2:00 PM, Matthew Giassa wrote: > Good day, > > I've been doing some testing with the bash-prexec script which uses a > DEBUG trap to issue user-supplied functions before executing each > command (https://github.com/rcaloras/bash-preexec). > > Here is a minimal working example > (https:

Question: is this a bug in BASh (pre-exec trap)

Good day, I've been doing some testing with the bash-prexec script which uses a DEBUG trap to issue user-supplied functions before executing each command (https://github.com/rcaloras/bash-preexec). Here is a minimal working example (https://github.com/rcaloras/bash-preexec/issues/25) which cause

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

  1   2   >