Re: Bash 5.1: Make shell_script_filename available to startup files
On Fri, Feb 16, 2024 at 9:45 PM Marc Aurèle La France
wrote:
> On Fri, 2024-Feb-16, Zachary Santer wrote:
>
> > And you're sure ${BASH_SOURCE[0]} wasn't what you wanted all along?
>
> Yes, but that doesn't matter now.
>
At the bottom of my .bashrc file:
printf '%s\n' "Hello, this script is ${BASH_SOURCE[0]}"
I start a new terminal and get:
Hello, this script is /home/zsant/.bashrc
How is this not what you wanted?
possible bash bug bringing job. to foreground
Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux HP-ProBook-6450b-500GB 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/LinuxMachine Type: x86_64-pc-linux-gnu Bash Version: 5.1Patch Level: 16Release Status: release Description: This is an attempted portion of a larger script I am writing. All these attempts appear valid; none works. BTW, also fails on termux 0.118.0/bash v5.22.6 (HOSTTYPE=aarch64, MACHTYPE=aarch64-unknown-linux-android) Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg %+; exit ) & Fix: (sleep 15s; set -m; kill $PPID) & Not a preferred solution; I prefer a smaller hammer.
Re: possible bash bug bringing job. to foreground
On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote: > Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg > %+; exit ) & You're using %% or %+ inside a shell where there have NOT been any background jobs created yet. The sleep 15s runs in the foreground, because it doesn't have a & after it. > Fix: (sleep 15s; set -m; kill $PPID) & Not a preferred solution; I prefer > a smaller hammer. It's not clear to me what you're trying to do in the first examples. Did you think that the subshell would somehow "take over" the terminal and become the interactive shell, after the 15 second delay? And what would that achieve, if it worked? In the "Fix" example, you're killing the main shell's parent, which is most likely a terminal emulator. Did you want to kill the main shell instead of the terminal? If so, you can get its PID with the $$ variable. Even inside a subshell, $$ always refers to the main shell's PID. If you want the subshell's PID, use BASHPID instead. What exactly is it about the "Fix" example that you don't prefer? What goal are you trying to achieve?
Re: [PATCH] use unlocked stdio functions
On 2/16/24 9:37 PM, Grisha Levit wrote: After this change, `make -C examples/loadables others` fails building necho.o with: use of undeclared identifier 'fflush_unlocked' I can't reproduce this on macOS, but these changes seem reasonable. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] use unlocked stdio functions
On Sat, Feb 17, 2024, 12:29 Chet Ramey wrote: > On 2/16/24 9:37 PM, Grisha Levit wrote: > > After this change, `make -C examples/loadables others` fails building > > necho.o with: > > > > use of undeclared identifier 'fflush_unlocked' > > I can't reproduce this on macOS, but these changes seem reasonable. > Same, macOS doesn't have fflush_unlocked. >
Re: Possible bug Bash v5.22.6/5.1.16
On 2/17/24 6:40 AM, John Larew wrote: This is a portion of a script that appears to be problematic. Each of these attempts appear to be valid; none of them work. The issue is apparent with bash in both termux v0.118.0/5.22.6 and Ubuntu v22.04.3 LTS/5.1.16 (see attached). The clue is in the error message (and its subsequent variants): fg: current: no such job which means that there are no background jobs in the execution environment where `fg' is executed. The background job in constructs like ( sleep 15s; set -m; fg %+; exit) & ( sleep 15s; set -m; fg %%; exit) & is in the parent shell's execution environment; the subshell has no background jobs of its own. In constructs like ( sleep 15s; set -m; fg $$; exit) & ( sleep 15s; set -m; fg $!; exit) & `fg' doesn't take PID arguments. (The reason you get the `current' in the error message is that $! expands to nothing if there haven't been any background jobs created, and `fg' without arguments defaults to the current job.) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: possible bash bug bringing job. to foreground
After further examination, the examples with "fg $$" and "fg $!" clearly do not bring the subshell into the foreground, as they are evaluated prior to the subshells background execution. I'm trying to bring the subshell to the foreground to perform an exit, after a delay. Ultimately, it will be used as part of a terminal emulator inactivity timeout. I suspected there are advantages to exiting the emulator vs. killing the process. Clearly, I misunderstood. Thanks again.
Re: possible bash bug bringing job. to foreground
On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do > not bring the subshell into the foreground, as they are evaluated prior to > the subshells background execution. > I'm trying to bring the subshell to the foreground to perform an exit, after > a delay. > Ultimately, it will be used as part of a terminal emulator inactivity timeout. Bash already has a TMOUT variable which will cause an interactive shell to exit after a specified length of inactivity. Is that sufficient? If not, how does your desired solution need to differ from TMOUT?
Re: Bash 5.1: Make shell_script_filename available to startup files
On Sat, 2024-Feb-17, Zachary Santer wrote:
On Fri, Feb 16, 2024, Marc Aurèle La France wrote:
On Fri, 2024-Feb-16, Zachary Santer wrote:
And you're sure ${BASH_SOURCE[0]} wasn't what you wanted all along?
Yes, but that doesn't matter now.
At the bottom of my .bashrc file:
printf '%s\n' "Hello, this script is ${BASH_SOURCE[0]}"
I start a new terminal and get:
Hello, this script is /home/zsant/.bashrc
How is this not what you wanted?
Do ...
rm -fr GREPME grepme
echo '#! /bin/bash\nset' > GREPME
"ln" GREPME grepme
chmod a+x grepme
... then (case matters) ...
BASH_ENV=GREPME ./grepme | fgrep -iw grepme
... gives ...
BASH_ARGV=([0]="GREPME")
BASH_ENV=GREPME
BASH_SOURCE=([0]="GREPME")
_=./grepme
BASH_ENV=GREPME
BASH_SOURCE=([0]="./grepme")
... so $_ wins, not $BASH_SOURCE[0]
Marc.
Re: Bash 5.1: Make shell_script_filename available to startup files
On Fri, 2024-Feb-16, Grisha Levit wrote: On Fri, Feb 16, 2024, Marc Aurèle La France wrote: On Mon, 2021-Feb-01, Marc Aurèle La France wrote: Currently, only the script's arguments are passed as positional parameters. For compatibility reasons, $0 cannot be used to also pass the script's filename, so I'm creating a new BASH_SCRIPT variable instead. --- bash-5.1/doc/bash.1 +++ devel-5.1/doc/bash.1 Yes, it's been three years, but... Withdrawn. I can accomplish the same thing by capturing $_ early on, before it gets clobbered by whatever. I believe bash-5.2 and up do behave the way you want w.r.t. the value of $0 when running the BASH_ENV script. See https://git.savannah.gnu.org/cgit/bash.git/tree/NEWS-5.2?h=devel#n58 : p. The `$0' special parameter is now set to the name of the script when running any (non-interactive) startup files such as $BASH_ENV. Yes, that works as well and is probably less fragile given how often $_ is set. Thanks. Marc.
Re: Bash 5.1: Make shell_script_filename available to startup files
On Sat, Feb 17, 2024 at 3:44 PM Marc Aurèle La France
wrote:
> Do ...
>
> rm -fr GREPME grepme
> echo '#! /bin/bash\nset' > GREPME
> "ln" GREPME grepme
> chmod a+x grepme
>
> ... then (case matters) ...
>
> BASH_ENV=GREPME ./grepme | fgrep -iw grepme
>
> ... gives ...
>
> BASH_ARGV=([0]="GREPME")
> BASH_ENV=GREPME
> BASH_SOURCE=([0]="GREPME")
> _=./grepme
> BASH_ENV=GREPME
> BASH_SOURCE=([0]="./grepme")
>
> ... so $_ wins, not $BASH_SOURCE[0]
>
Sorry I didn't read your original email chain from 2021 before responding
earlier.
You want a script sourced because it's given as ${BASH_ENV} to be able to
tell what script it was sourced from?
If you're satisfied with $_ or now $0, then fine, but I would actually
expect that to show up as ${BASH_SOURCE[1]} within the ${BASH_ENV} script,
which it obviously doesn't. Don't know what ${BASH_LINENO[0]} ought to be
in that case. Maybe 0?
The way the manual explains BASH_SOURCE and BASH_LINENO is all in
reference to FUNCNAME, which doesn't exist (or is empty) if you're not
executing a function. Still, with explicit sourcing, this is the behavior
we see:
zsant@Zack2021HPPavilion MINGW64 ~/random
$ cat original-file
#!/bin/bash
source ./sourced-file
zsant@Zack2021HPPavilion MINGW64 ~/random
$ cat sourced-file
declare -p BASH_SOURCE BASH_LINENO
zsant@Zack2021HPPavilion MINGW64 ~/random
$ ./original-file
declare -a BASH_SOURCE=([0]="./sourced-file" [1]="./original-file")
declare -a BASH_LINENO=([0]="2" [1]="0")
So this would seemingly be more consistent and not require a whole new
shell variable.
Re: Bash 5.1: Make shell_script_filename available to startup files
On Sat, 2024-Feb-17, Zachary Santer wrote:
On Sat, Feb 17, 2024, Marc Aurèle La France wrote:
Do ...
rm -fr GREPME grepme
echo '#! /bin/bash\nset' > GREPME
"ln" GREPME grepme
chmod a+x grepme
... then (case matters) ...
BASH_ENV=GREPME ./grepme | fgrep -iw grepme
... gives ...
BASH_ARGV=([0]="GREPME")
BASH_ENV=GREPME
BASH_SOURCE=([0]="GREPME")
_=./grepme
BASH_ENV=GREPME
BASH_SOURCE=([0]="./grepme")
... so $_ wins, not $BASH_SOURCE[0]
Sorry I didn't read your original email chain from 2021 before responding
earlier.
You want a script sourced because it's given as ${BASH_ENV} to be able to
tell what script it was sourced from?
If you're satisfied with $_ or now $0, then fine, but I would actually
expect that to show up as ${BASH_SOURCE[1]} within the ${BASH_ENV} script,
which it obviously doesn't. Don't know what ${BASH_LINENO[0]} ought to be
in that case. Maybe 0?
The way the manual explains BASH_SOURCE and BASH_LINENO is all in
reference to FUNCNAME, which doesn't exist (or is empty) if you're not
executing a function. Still, with explicit sourcing, this is the behavior
we see:
zsant@Zack2021HPPavilion MINGW64 ~/random
$ cat original-file
#!/bin/bash
source ./sourced-file
zsant@Zack2021HPPavilion MINGW64 ~/random
$ cat sourced-file
declare -p BASH_SOURCE BASH_LINENO
zsant@Zack2021HPPavilion MINGW64 ~/random
$ ./original-file
declare -a BASH_SOURCE=([0]="./sourced-file" [1]="./original-file")
declare -a BASH_LINENO=([0]="2" [1]="0")
So this would seemingly be more consistent and not require a whole new
shell variable.
Well, I may find what you describe useful at some point, but for now $0
will do.
Thanks.
Marc.
