Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux bomb20 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9
22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 4
Release Status: maint
Description:
The
guments are silently ignored
$ pwd
/tmp
$ dirs
/tmp
$
3.2.48 is the version installed by Ubuntu. I see the same issue with
bash version 4.1.0(1)-release (compiled from source on the same system).
(For what it's worth, tcsh and ksh both give error messages.)
--
Keith Thompson (The_Oth
Keith Thompson writes:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
>
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments ar
gout" before it exits just
> as if I would press ^D on prompt. I have tried putting "gitk &" call
> into a script and adding traps for all possible signals but none seemed
> to be fired.
> You do not have to be in a directory that is a Git repository.
I wonder how
Keith Thompson writes:
> "Illia Bobyr" writes:
> [...]
>> When I do "gitk &" upon gitk exit the parent bash process
>> terminates as well.
>> When I do "(gitk &)" it works fine. There does not seem to be any
>> cr
@ then @code{$0} is set to the first argument
after the string to be
executed, if one is present. Otherwise, it is set
to the filename used to invoke Bash, as given by argument zero.
-@item _
+@item $_
(An underscore.)
At shell startup, set to the absolute pathname used to invoke the
shell or s
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux bomb20 4.8.0-46-generic #49-Ubuntu SMP Fri Mar 31
13:57:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Mac
In the documentation for the "mapfile" builtin command:
'-C'
Evaluate CALLBACK each time QUANTUMP lines are read. The '-c'
option specifies QUANTUM.
"QUANTUMP" should be "QUANTUM".
In the latest sources cloned from git://git.savannah.gnu.org/bash.git, this
occurs in:
b
On Thu, Jun 29, 2017 at 6:56 AM, Eduardo A. Bustamante López
wrote:
> On Wed, Jun 28, 2017 at 07:08:27PM -0700, Keith Thompson wrote:
> [...]
>> mapfile REDIRECT < /tmp/input.txt
>> cat /tmp/input.txt | mapfile PIPE
>
> The `mapfile PIPE' is a piec
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
inition of Epoch).
Assignments to @env{EPOCHSECONDS} are ignored.
-- Keith Thompson
can rely on it.
${EPOCHREALTIME: -6}
On Tue, Jan 8, 2019 at 2:13 AM Andreas Schwab wrote:
>
> On Jan 07 2019, Keith Thompson wrote:
>
> > I suggest documenting this behavior. It would be nice to be able to
> > depend on the exact format, for example that ${EPOCHREALTIME/*./}
> &g
From: kst
To: bug-bash@gnu.org
Subject: echo vs /bin/echo appears to affect variable scope
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux bomb20 4.1
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security
uname output: Linux bomb20 5.4.0-31-generic #35-Ubuntu SMP Thu May 7
20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine
On Fri, May 29, 2020 at 11:40 AM Chet Ramey wrote:
>
> On 5/28/20 6:12 PM, Keith Thompson wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -g -
On Mon, Jun 1, 2020 at 6:05 AM Chet Ramey wrote:
> On 5/29/20 2:50 PM, Keith Thompson wrote:
>
> >> Can you try this with the current devel branch head from savannah? I
> >> have a suspicion about what's going on.
> >>
> >> http://git.savannah.g
On Mon, Jun 1, 2020 at 12:12 PM Chet Ramey wrote:
>
> On 6/1/20 3:04 PM, Keith Thompson wrote:
>
> > OK, that's half of it.
> >
> > If you have a chance, can you verify that the problem exists with the
> > bash-20200520 push?
> >
> >
was invoked when I interrupted the
"cat" command the first
time, but not the second time.
The original version of the "trap" command was:
show_error() { printf "\e[1mExit $?\e[m\n" ; }
trap show_error ERR
intended to mimic tcsh's $printexitvalue setting.
--
Keith Thompson
TRACE: pid 3822: xparse_dolparen:17: ep[-1] != RPAREN
(33), ep = `'
TRACE: pid 3822: xparse_dolparen:17: base[8] != RPAREN (33), base = `echo
$(!!'
--
Keith Thompson
im) invoked from "git commit".
So apparently it has something to do with a full-screen program invoked
by some other program.
Let me know if I can provide more information (Debian 6 is fairly old, so
you might not have a running copy).
--
Keith Thompson
ss by typing "kill -STOP PID" from
another terminal. After doing that, I can restore it by typing "fg"
at the bash prompt (but Ctrl-Z still doesn't work).
This problem occurs with bash 4.4-beta on Debian 6.0.10. It does not
occur with bash 4.4-beta on Linux Mint 17.2, or w
1d0e3000)
But I see the same difference on /bin/bash (4.1.5 on the Debian system,
4.3.11 on the Linux Mint system).
On Thu, Oct 29, 2015 at 5:31 PM, Mike Frysinger wrote:
> what does `stty -a` show on the two systems ?
>
> what version of readline are you using on both ?
> -mike
>
--
Keith Thompson
n setup scripts.
I'll investigate further and get back to you.
On Fri, Oct 30, 2015 at 3:55 AM, Chet Ramey wrote:
> 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 Deb
Any suggestions on more data I can gather if this happens again?
I can try attaching strace and sending a copy of the log.
On Fri, Oct 30, 2015 at 2:31 PM, Keith Thompson
wrote:
> I just tried it on a two VMs running Debian 6 and 7, respectively.
> The problem did not occur.
>
> It
$ 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
in place
before typing Enter, but it has the side effect of stripping quotes from
what I've already typed.
--
Keith Thompson
Yes this is useful. I've set it up to happen automatically with
> this in my .inputrc
>
> $if Bash
> # do history expansion when space entered
> Space: magic-space
> $endif
>
> cheers,
> Pádraig.
>
--
Keith Thompson
ve to use it.
On Fri, Nov 6, 2015 at 5:12 AM, Chet Ramey wrote:
> On 11/4/15 1:48 PM, Keith Thompson wrote:
> > Thanks, I didn't know about history-expand-line.
> >
> > Is there some case where shell-expand-line would actually be useful?
> > If I've typed *&q
https://gist.github.com/Keith-S-Thompson/c842663ace93c23fabd7
On Sat, Oct 31, 2015 at 12:45 PM, Keith Thompson
wrote:
> $ trap
> trap -- 'show_error' ERR
> $ type show_error
> show_error is a function
> show_error ()
> {
> printf "\e[1mExit $?\e[m\n" 1
Is there a workaround, a way to re-enable correct Ctrl-Z handling?
On Tue, Nov 10, 2015 at 7:33 AM, Chet Ramey wrote:
> 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
r rxvt or urxvt won't be able to use Ctrl-Z. If it's rxvt that's
buggy, I'll
contact the rxvt and urxvt maintainers (and I'll probably recompile my own
version with those lines commented out).
--
Keith Thompson
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 > <mailto:chet.ra...@case.edu>> wrote:
> >
> >
> >
> > It seems like you need to figure out w
) has the same behaviour there is probably no
> alternative.
>
> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
Ctrl-Z works correctly.
I verified that the shell's parent process was "login".
Perhaps (at least the Debian version of) login(1) *doesn't* do that.
--
Keith Thompson
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 whe
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
> > <mailto:keithsthomp...@gmail.com>> wrote:
> >
> > On Tue, Nov 1
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
>> > &
: ulimit [-SHabcdefilmnpqrstuvxT] [limit]
$ /_opt/apps/bash-4.4-beta/bin/bash -c 'echo $BASH_VERSION ; ulimit --help'
4.4.0(1)-beta
/_opt/apps/bash-4.4-beta/bin/bash: xrealloc: ./ulimit.def:382: cannot
allocate 4294967296 bytes (8590045184 bytes allocated)
$
--
Keith Thompson
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto
-ffat-lto-objects -fstack-protector-strong -fstack-clash-p
:abc:abc:
$
On Mon, Dec 2, 2024 at 11:51 AM Chet Ramey wrote:
>
> On 12/2/24 12:52 AM, Keith Thompson wrote:
>
> > Bash Version: 5.2
> > Patch Level: 32
> > Release Status: release
> >
> > Description:
> > If the wordlist given to `complete -W` includ
On Tue, Dec 3, 2024 at 10:20 AM Chet Ramey wrote:
>
> On 12/2/24 7:29 PM, Keith Thompson wrote:
> > OK, that explains the problem, and I have a workaround.
> >
> > (Background: I have a personal tool that uses "foo:bar" syntax for
> > some of its arguments
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto
-ffat-lto-objects -fstack-protector-strong -fstack-clash-p
On Fri 2025-01-24 11:45:22 EST, Chet Ramey wrote:
> On 1/23/25 9:15 PM, Keith Thompson wrote:
>
> > But I don't see anything in the "Tilde Expansion" section that
> > documents the behavior of a literal '~' in $PATH.
>
> It remains undocumented.
T
On Thu, Jan 23, 2025 at 5:31 PM Lawrence Velázquez wrote:
>
> On Thu, Jan 23, 2025, at 6:37 PM, Keith Thompson wrote:
> > Description:
> > A literal '~' or other tilde-prefix at the beginning of an
> > element of $PATH is expanded when a command is exe
43 matches
Mail list logo
