Re: size_t issue in expand_string_dollar_quote
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 fix but the issue is here: It's not unreasonable. -- ``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/
Re: Bash Reference Manual Type
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/V1_chap12.html#tag_12 > > > > You'll see this used in many man pages, usage messages and other > > documentation. It's by no means specific to Bash. > > I would be interested in an example! > > Best regards, > > Martin > Examples of man pages and help text: man man man grep grep -h man find man ssh ssh --help man lsof lsof -h An example of the synopsis section of the lsof man page Revision-4.91 on my Mac: SYNOPSIS lsof [ -?abChlnNOPRtUvVX ] [ -A A ] [ -c c ] [ +c c ] [ +|-d d ] [ +|-D D ] [ +|-e s ] [ +|-E ] [ +|-f [cfgGn] ] [ -F [f] ] [ -g [s] ] [ -i [i] ] [ -k k ] [ -K k ] [ +|-L [l] ] [ +|-m m ] [ +|-M ] [ -o [o] ] [ -p s ] [ +|-r [t[m]] ] [ -s [p:s] ] [ -S [t] ] [ -T [t] ] [ -u s ] [ +|-w ] [ -x [fl] ] [ +|-X ] [ -z [z] ] [ -Z [Z] ] [ -- ] [names] Part of the output of lsof -h: usage: [-?abhlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-f[cgG]] [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+|-M] [-o [o]] [-p s] [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names] (Side notes: the missing spaces are just as it was output, some options aren't shown in the help output, -e for example) I apologize if the formatting of the preceding is unreadable. They are direct copy/pastes. >
Re: Bash Reference Manual Type
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]]] [-@] [dir]
| > ^ ^
| > But aren't these two brackets just superfluous?
|
| -L and -P are mutually exclusive, and -e is valid only when -P is
| supplied.
-e only means anything when -P is specified, but there's no reason
to prohibit its use without -P, it simply does nothing in that case,
the option is simply meaningless. (Better to prohibit -L, that's a
loony option - but also a whole different issue.)
The real issue here however is that there is no defined notation for
expressing these usage synopses. What that means is that it isn't
specified whether alternation ('|') or concatenation (' ') has higher
precedence.
That is, whether
cd [ -L | -P [-e] ]
means (with the addition of parentheses, which are never really
used in these things, or users would try to type them, just to make
precedence explicit)
cd [ -L | ( -P [-e] ) ]
or
cd [ ( -L | -P ) [-e] ]
In most languages the former would be the interpretation, but as there
is no spec for this one, we really don't know. What we do know is that
we should be consistent. If the first interpretation is the one that
applies, then the extra [] around -P [-e] aren't necessary. If the second
is, then they are, but in that case
cd -L | [-P [-e]] [-@]...
would be sufficient, as that would be interpreted as
cd ( -L | ( [ -P [-e]] ) ) [-@]...
(the assumption is that alternation has higher precedence than
concatenation - we don't need to make the -L explicitly optional,
as its alternative can be empty, so to omit both -L and -P, we
would just take 2nd alternative (the optional -P) and then not
take the option.
But all of this is just intended to be a hint to users as to what
is possible, sometimes we'd make it clearer and give multiple
different possible synopsis lines
cd [-L] [-@] [dir]
cd -P [-e] [-@] [dir]
which can be clearer, but takes more space.
All of this is why (in the manual anyway) no-one should ever rely
upon the synopsis to convey much more than a hint - the text should
always be explicit about which "options" are required (if any), which
are mutually exclusive, ...
kre
Re: Bash Reference Manual Type
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 valid only when -P is > > supplied. > > Yes, my feeling was just that | has such a low precedence that the marked > pair of brackets could be omitted, like in > id|cut -c1-3 > or in the ERE > ^(-L|-P( -e)?)?$ > > But situation seems to be different here. > > Best regards, > > Martin > This isn't regex. 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/V1_chap12.html#tag_12 You'll see this used in many man pages, usage messages and other documentation. It's by no means specific to Bash.
Re: Bash Reference Manual Type
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 such a low precedence that the marked pair of brackets could be omitted, like in id|cut -c1-3 or in the ERE ^(-L|-P( -e)?)?$ But situation seems to be different here. Best regards, Martin
Re: Bash Reference Manual Type
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 short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: IFS field splitting doesn't conform with POSIX
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 allowing for their idiosyncrasies is more involved than you seem to think. This is well put. -- ``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/
Re: IFS field splitting doesn't conform with POSIX
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 long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: IFS field splitting doesn't conform with POSIX
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 field is generated. Initially I was going to report the bug in zsh, until I read what the POSIX specification says about field splitting [1]. Yes, the current wording is sort of a mess. It's one of those places in the standard where everyone "knows" what is supposed to happen, even if it's not spelled out explicitly. This issue came up to the POSIX group three times: 1995, 1998, and most recently in 2005. The 1995 interpretation confirms that a trailing IFS character does not delimit an empty field: https://www.open-std.org/jtc1/sc22/WG15/docs/rr/9945-2/9945-2-98.html The 2005 discussion accepted that a trailing IFS character does not generate a final empty field, since that reflected existing practice back to the Bourne shell, and primarily concentrated on how word splitting and `read' interact. My guess is the intent is that the text about "non-zero-length IFS whitespace shall delimit a field" is supposed to cover this case, but it requires a creative reading of the text to get there. kre filed an interpretation request to get the language cleaned up. 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/
Re: Bash Reference Manual Type
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
Re: Bash Reference Manual Type
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
Re: Bash Reference Manual Type
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 [-e]] [-@]] [dir] So it looks like the documentation is missing the last closing right bracket after the @ symbol. Thanks for the report. The synopsis should read cd [-L|[-P [-e]]] [-@] [dir] -- ``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/
Bash Reference Manual Type
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 documentation is missing the last closing right bracket after the @ symbol.
