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 ...
B
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")
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 fil
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'
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 fo
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
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 e
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 se
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
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
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-5
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 ${BAS
12 matches
Mail list logo
