The size of the buffer used for printf -v is tracked in an int but this
can overflow since the buffer can be built up by multiple vsnprintf(3)
calls, each of which can append up to INT_MAX bytes to the buffer:
$ INT_MAX=$(getconf INT_MAX)
$ printf -v VAR "%$((INT_MAX-1))s%$((INT_MAX-1))s"
Chet has since pointed out that the debugger is not involved at all.
On Mon, 22 Jan 2024, 18:17 Grisha Levit, wrote:
>
> That's not quite what happens. These scripts get executed by forking the
> current bash process (without exec). The new shell resets its state and
> runs the script.
>
I'm br
Hello,
I've encountered what I believe is a bug in bash's "wait -n". wait -n
fails to return for processes that terminate due to a signal prior to
calling wait -n. Instead, it returns 127 with an error that the
process id cannot be found. Calling wait (without -n) then
returns its exit code (e.
On 1/22/24 8:02 AM, Oğuz wrote:
On Mon, Jan 22, 2024 at 3:25 PM Greg Wooledge wrote:
But in any case, writing a "script" without a shebang and then counting
on the shell to work around the broken script is not ideal.
Unlike shebangs that behavior is standardized. Which is what I
consider ideal
On 1/22/24 1:53 AM, Martin D Kealey wrote:
Hi Oğuz
On Sun, 21 Jan 2024 at 03:20, Oğuz wrote:
$ echo echo foo bar >s
$ chmod +x s
You seem to have created an invalid executable. It seems that scripts
without a #! can only be run with help from the debugger library;
This isn't co
On 1/20/24 12:20 PM, Oğuz wrote:
See:
$ echo echo foo bar >s
$ chmod +x s
$ f(){ COMPREPLY=($(bash ./s));}
$ complete -F f g
$
$ g
bar foo
$ g ^C
$
$ f(){ COMPREPLY=($(./s));}
$ g ^C^C
$
I press tab after typing `g ' in bo
On Mon, Jan 22, 2024 at 3:25 PM Greg Wooledge wrote:
> But in any case, writing a "script" without a shebang and then counting
> on the shell to work around the broken script is not ideal.
Unlike shebangs that behavior is standardized. Which is what I
consider ideal. Thanks for your input
On Mon, Jan 22, 2024 at 12:17:12PM +0200, Oğuz wrote:
> On Monday, January 22, 2024, Martin D Kealey
> wrote:
> >
> > You seem to have created an invalid executable. It seems that scripts
> > without a #! can only be run with help from the debugger library
> >
>
> Hi Martin, POSIX shells interpre
On Monday, January 22, 2024, Martin D Kealey
wrote:
>
> You seem to have created an invalid executable. It seems that scripts
> without a #! can only be run with help from the debugger library
>
Hi Martin, POSIX shells interpret such executables as shell scripts, I
don't think bash would take a h
On Mon, Jan 22, 2024, 01:54 Martin D Kealey wrote:
> You seem to have created an invalid executable. It seems that scripts
> without a #! can only be run with help from the debugger library;
That's not quite what happens. These scripts get executed by forking the
current bash process (without e
10 matches
Mail list logo
