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
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 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
: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
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
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
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?
> >
> >
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 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 -
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
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
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
inition of Epoch).
Assignments to @env{EPOCHSECONDS} are ignored.
-- Keith Thompson
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
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
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
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
: 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
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
>> > &
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 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
) 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 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
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
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
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
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
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
in place
before typing Enter, but it has the side effect of stripping quotes from
what I've already typed.
--
Keith Thompson
$ 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
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
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
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
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
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
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
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
@ 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
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
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:
> 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
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
43 matches
Mail list logo
