Bump in case this fell through the cracks. My simple script that uses no job
control facilities (in fact, turns job control off) if run in the background
would log the user out on any keyboard input. This can't be right. Can you at
least confirm that this is indeed a bug in Bash? Are there any
Date:Tue, 25 Jun 2024 10:25:48 -0400
From:Chet Ramey
Message-ID: <983be032-0b60-4313-a18a-5fd74d5b5...@case.edu>
| On 6/24/24 4:36 PM, Gioele Barabucci wrote:
| > the manpage states:
| >> The --rcfile file option will force bash to
| >> read and execute comman
On 6/24/24 2:51 PM, r...@csail.mit.edu wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
When I run bash under valgrind, and run set -o vi, and then type
ESC d 1 C
valgrind says
Invalid read of size 4
at 0x1D536A: _rl_vi_domove_motion_cleanup (vi_mode.c:
On 6/19/24 6:12 PM, konsolebox wrote:
Alternatively, have BASH_SOURCE always produce real physical paths
either by default or through a shopt.
This is the best option. I don't think changing bash to do this by default
would have negative side-effects.
--
``The lyf so short, the craft so long
On 6/21/24 10:01 AM, Martin D Kealey wrote:
I support BASH_SOURCE_PATH as replacing the normal PATH search only for "."
and "source".
I implemented the -p option to ./source instead.
In addition I propose some new '~' expansions which will give concise
expression of dirname+realpath without p
On 6/24/24 4:36 PM, Gioele Barabucci wrote:
Hi,
the manpage states:
When an interactive shell that is not a login shell is started, bash
reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
these files exist. […] The --rcfile file option will force bash to
read and execute comm
On Tue, Jun 25, 2024 at 3:32 PM Emanuele Torre wrote:
> There are actually ways to call them:
>
> $ %f(){ echo hi;}
> $ compgen -F %f
> bash: compgen: warning: -F option may not work as you expect
> hi
Neat
On Mon, Jun 24, 2024 at 09:37:42PM +0300, Oğuz wrote:
> You can do these
>
> $ %f(){ :;}
> $ declare -f %f
> %f ()
> {
> :
> }
> $ unset -f %f
> $ declare -f %f
> $ echo $?
> 1
>
> but not call them
>
> $ %f
> bash: fg: %f: no such job
> $ '%f'
> bash: fg: %f: no such job
> $ \%f
> bash: fg:
On Mon, Jun 24, 2024 at 2:37 PM Oğuz wrote:
> $ %f
> bash: fg: %f: no such job
> $ '%f'
> bash: fg: %f: no such job
> $ \%f
> bash: fg: %f: no such job
Set +m won't fix this either.
$ %f(){ :;}
$ %f
-bash: fg: %f: no such job
$ set +m
$ %f
-bash: fg: no job control
Unlike ! in an arithmetic con
On Tue, Jun 25, 2024 at 4:05 AM Martin D Kealey wrote:
> • Normally it's expected that if any part of a pipeline exits, all
> preceding parts would eventually receive SIGPIPE upon writing to stdout.
To expand on this a bit, when a process exits because of receiving a
signal like SIGPIPE, it will
Conceptually this sounds useful, but how exactly would it work?
• Is any attempt made to terminate the other processes in the pipeline, or
to you just not delay by waiting for them immediately?
→ If attempting to terminate:
- using which signal?
- what happens if the process refuses to d
11 matches
Mail list logo
