On 3/29/23 6:28 PM, Grisha Levit wrote:
bash --norc -in <<<$'"\e\cE'
ERROR: AddressSanitizer: negative-size-param: (size=-1)
#0 wrap_strncpy+0x228
#1 expand_string_dollar_quote subst.c:4108
#2 shell_expand_line bashline.c:2887
Thanks for the report.
probably not the cleanest f
On Fri, Mar 31, 2023, 3:02 PM Martin Schulte
wrote:
> Hi Dennis,
>
> thanks for your answer!
>
> > This isn't regex.
>
> Sure!
>
> > It's a command synopsis using a long standing notation
> > style. You can see it set out in POSIX in
> >
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs
Date:Fri, 31 Mar 2023 14:41:37 -0400
From:Chet Ramey
Message-ID: <625e93f4-280b-2cd4-f84d-2305bd347...@case.edu>
| On 3/31/23 12:30 PM, Martin Schulte wrote:
| > Hi Chet!
| >
| >> Thanks for the report. The synopsis should read
| >>
| >> cd [-L|[-P [-e]]]
On Fri, Mar 31, 2023, 2:47 PM Martin Schulte
wrote:
> Hi Chet!
>
> > >> Thanks for the report. The synopsis should read
> > >>
> > >> cd [-L|[-P [-e]]] [-@] [dir]
> > > ^ ^
> > > But aren't these two brackets just superfluous?
> >
> > -L and -P are mutually exclusive, and -e is va
Hi Chet!
> >> Thanks for the report. The synopsis should read
> >>
> >> cd [-L|[-P [-e]]] [-@] [dir]
> > ^ ^
> > But aren't these two brackets just superfluous?
>
> -L and -P are mutually exclusive, and -e is valid only when -P is
> supplied.
Yes, my feeling was just that | has s
On 3/31/23 12:30 PM, Martin Schulte wrote:
Hi Chet!
Thanks for the report. The synopsis should read
cd [-L|[-P [-e]]] [-@] [dir]
^ ^
But aren't these two brackets just superfluous?
-L and -P are mutually exclusive, and -e is valid only when -P is
supplied.
--
``The lyf so s
On 3/30/23 3:18 PM, Lawrence Velázquez wrote:
In my view if POSIX was merely descriptive, then the Austin Group
would have no need to discuss much, as it's fairly easy to describe
what current shells do.
Composing technical specifications that describe implementations'
shared behaviors while a
On 3/30/23 12:51 PM, Felipe Contreras wrote:
It could very well mean that all shells are implementing POSIX wrong.
Except zsh.
No, interpretations have confirmed that not generating a final empty field
is correct. It's just not clear enough in the text.
--
``The lyf so short, the craft so lon
On 3/30/23 7:12 AM, Felipe Contreras wrote:
Hi,
Consider this example:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
There is a discrepancy between how this is interpreted between bash
and zsh: in bash the last comma doesn't generate a field and is
ignored, in zsh a last empty
On Fri, Mar 31, 2023 at 06:30:00PM +0200, Martin Schulte wrote:
> Hi Chet!
>
> > Thanks for the report. The synopsis should read
> >
> > cd [-L|[-P [-e]]] [-@] [dir]
> ^ ^
> But aren't these two brackets just superfluous?
Then -L would get the -e too.
--
Regards, Mike Jonkmans
Hi Chet!
> Thanks for the report. The synopsis should read
>
> cd [-L|[-P [-e]]] [-@] [dir]
^ ^
But aren't these two brackets just superfluous?
Best regards,
Martin
On 3/31/23 3:42 AM, Ikenna West wrote:
Hello, I was going looking through the Bash reference manual and I noticed
that on page 55, when it lists the options for the cd command it is written
as cd [-L|[-P [-e]] [-@] [directory]. However, when typing help cd into
Bash it prints out
cd [-L | [-P
Hello, I was going looking through the Bash reference manual and I
noticed that on page 55, when it lists the options for the cd command it
is written as cd [-L|[-P [-e]] [-@] [directory]. However, when typing
help cd into Bash it prints out
cd [-L | [-P [-e]] [-@]] [dir]
So it looks like the
13 matches
Mail list logo
