While you're at it take a look at this too:
true; for (( ; $? == 0; ${ ! break;} )); do uname; done
Once you run this command bash gets stuck in a state where it prints
the prompt string and reads commands but doesn't execute anything. If
you press Ctrl+C it returns to normal.
Oğuz
Hi Chet,
In this commit in the devel branch:
commit 03c8c43b79177fa678714893e9f05b1c517592c0
Author: Chet Ramey
Date: Fri Apr 5 09:03:52 2024 -0400
man page typesetting updates for compatibilityand layout issues
I think there was a typo in execute_cmd.c:
diff --git a/execute_cmd.c b/exe
On Thu, May 23, 2024 at 3:55 PM Chet Ramey wrote:
>
> On 5/23/24 7:43 AM, Michael Maurer wrote:
>
> > Bash Version: 5.2
> > Patch Level: 15
> > Release Status: release
> >
> > Description:
> > Calling a function that itself uses the keyword "time" to call
> > another function that performs
On Thu, May 23, 2024 at 4:11 PM Chet Ramey wrote:
>
> On 5/23/24 3:25 PM, Grisha Levit wrote:
> > On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote:
> >>
> >> On 5/21/24 2:42 PM, Grisha Levit wrote:
> >>> Avoid using (size_t)-1 as an offset.
> >>
> >> I can't reproduce this on macOS. Where is the
On 5/23/24 3:25 PM, Grisha Levit wrote:
On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote:
On 5/21/24 2:42 PM, Grisha Levit wrote:
Avoid using (size_t)-1 as an offset.
I can't reproduce this on macOS. Where is the code that's using -1 as an
offset?
The loop in rl_change_case does the foll
On 5/23/24 7:43 AM, Michael Maurer wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Calling a function that itself uses the keyword "time" to call another
function that performs a long task, and then interrupting with Ctrl+C before it is
complete, causes a
On Thu, May 23, 2024 at 10:25 AM Chet Ramey wrote:
>
> On 5/21/24 2:42 PM, Grisha Levit wrote:
> > Avoid using (size_t)-1 as an offset.
>
> I can't reproduce this on macOS. Where is the code that's using -1 as an
> offset?
The loop in rl_change_case does the following:
rl_change_case(count=-
See:
$ bash -c 'for (( $(case x in x) esac);; )); do :; done'
bash: -c: line 1: syntax error: `;' unexpected
bash: -c: line 1: syntax error: `(( $(case x in x)
;;
esac);; ))'
This is reproducible on 5.3 alpha too.
Oğuz
On 5/21/24 2:42 PM, Grisha Levit wrote:
Avoid using (size_t)-1 as an offset.
I can't reproduce this on macOS. Where is the code that's using -1 as an
offset?
Also, not sure it makes sense to
change the case of an invalid byte cast to (wchar_t).
Bash and readline are pretty consistent about
if u
var=value command ;
the var's only for cmd and disappears afterwards
if u
var=val ; cmd ;
its not for cmd , excepts exported
and is set after cmd , usual behav
old rule
On Thu, May 23, 2024, 3:34 PM Robert Elz wrote:
> Date:Thu, 23 May 2024 09:04:48 -0400
> From:Ch
Date:Thu, 23 May 2024 09:04:48 -0400
From:Chet Ramey
Message-ID:
| The bash output clearly tells you the
| order of operations, which is the whole purpose of -x.
But it can be horribly misleading. Consider what bash does with
this similar case (I used 5.3a1 b
On 5/22/24 10:57 PM, Oğuz wrote:
And some Bourne shells expand command substitutions first
$ (exit 5)
$ x=$? y=`exit 10`
$ echo $x
10
It's worse than that. The v7 sh performed assignments right to left.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars lon
On 5/22/24 6:56 PM, Dan Jacobson wrote:
It seems these should both make one line "+ a=b c=b" output,
for s in sh bash
do $s -xc 'a=b c=$a'
done
I mean they give the same results, but bash splits it into
two lines, so the user reading the bash -x output cannot tell
if one (correct) or two (incor
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux nb 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1
(2024-04-11) x86_
14 matches
Mail list logo
