Re: Add warning on test -a, -o documentation
On 2/13/19 8:08 PM, 積丹尼 Dan Jacobson wrote: > On the bash man page at > expr1 -a expr2 > True if both expr1 and expr2 are true. > expr1 -o expr2 > True if either expr1 or expr2 is true. > and on "help test" perhaps add the same warning as one sees on > (info "(coreutils) Connectives for test"). I'll stick with the POSIX description based on the number of arguments instead of the contradictory description in the coreutils info document. -- ``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 5.0 ships with very old autoconf macros
On 2/12/19 4:08 PM, Christian Weisgerber wrote: > The bash 5.0 release still ships with very old autoconf macros to > detect gettext. In aclocal.m4, the copy of gettext.m4 and the > supporting lib-link.m4 are from gettext-0.12 dating from 2003. > > In particular, the included version of AC_LIB_LINKFLAGS_BODY cannot > detect shared libraries on OpenBSD. (It checks for *.so; OpenBSD > only has fully numbered libraries: *.so.0.0, etc.) > > These macros should be updated to newer versions from a recent > release of gettext. I took a look at doing this. After adding almost 40 files to the distribution, I satisfied all the m4 dependencies, and it seems to build successfully. -- ``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/
Why { is parsed differently depending on the context?
Hi,
`echo {` treats `{` as WORD.
`{ echo; }` treats `{` as a token of `{`.
`{a` treats `{a` as a WORD.
I don't see the point why yylex() treat `{` context dependently.
Wouldn't it better just treat a bare `{` as a token of `{`?
What is the reasoning behind the current design of the syntax?
--
Regards,
Peng
About ARITH_CMD
Hi, yylex() still gives the token ARITH_CMD for the following command. The error seems to be raised at the parsing stage. Shouldn't the error be caught in the lexical analysis stage? $ ((x = 10 + 5; ++x; echo $x)) bash: ((: x = 10 + 5; ++x: syntax error: invalid arithmetic operator (error token is "; ++x") Why the parsing of the arithmetic expression is in the lexical analysis. Why not introduce token `((` and `))` and handle arithmetic expression in the bison parsing code? Also, I don't find that POSIX specifies `((`. (Let me know if I miss anything.) If `((` is a bash-specific thing, why not allow it to handle multiple arithmetic expressions instead of just one? Thanks. http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html -- Regards, Peng
Re: Why { is parsed differently depending on the context?
On 2/14/19 11:05 AM, Peng Yu wrote:
> Hi,
>
> `echo {` treats `{` as WORD.
>
> `{ echo; }` treats `{` as a token of `{`.
>
> `{a` treats `{a` as a WORD.
>
> I don't see the point why yylex() treat `{` context dependently.
> Wouldn't it better just treat a bare `{` as a token of `{`?
>
> What is the reasoning behind the current design of the syntax?
Historical practice. And it is for the same reason that 'if' is treated
as IF when it appears in certain spots (as in 'if :; then ...', but as a
WORD in others (as in 'echo if'). Basically, '{' is a reserved word,
and NOT an operator, so it does NOT get the same treatment as '(', '<',
and so on. Changing it now would break scripts that have relied on the
fact that '{' is parsed as a reserved word when in the correct
syntactical locations (and therefore '{}' does not need quoting because
it is not spelled the same as a reserved word) rather than an operator
(where constructs like 'find . -exec {} \;' would be broken).
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10
may be a helpful read for rules on deciding whether a TOKEN is further
resolved into reserved word or a plain WORD (although remember that
bash's parser recognizes more things than are required by the POSIX grammar)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
bug-bash@gnu.org
Hi, regarding the paste security issues (pastejacking) [1] there is one last thing that shall be done to make it possible for terminal emulators to enable a secure shell by default: Enable bracket pasting mode in bash, by default. For details, see https://gitlab.gnome.org/GNOME/vte/issues/92, demo https://thejh.net/misc/website-terminal-copy-paste. GNOME Terminal e.g. mitigated this, but without a proper default of the shell, it won't help. Best regards, rugk [1] https://bugzilla.gnome.org/show_bug.cgi?id=697571
Re: About ARITH_CMD
On 2/14/19 4:03 PM, Peng Yu wrote:
> Hi,
>
> yylex() still gives the token ARITH_CMD for the following command. The
> error seems to be raised at the parsing stage. Shouldn't the error be
> caught in the lexical analysis stage?
Changing it now may break scripts that depend on the existing behavior.
>
> $ ((x = 10 + 5; ++x; echo $x))
> bash: ((: x = 10 + 5; ++x: syntax error: invalid arithmetic operator
> (error token is "; ++x")
>
> Why the parsing of the arithmetic expression is in the lexical
> analysis. Why not introduce token `((` and `))` and handle arithmetic
> expression in the bison parsing code?
Because there are other situations where bash has chosen to let '(('
represent the start of nested subshells; blindly always treating two
consecutive (( as a single token would make the treatment of nested
subshells harder to write (even if such code is not portable according
to POSIX).
>
> Also, I don't find that POSIX specifies `((`. (Let me know if I miss
> anything.)
POSIX does not specify it, other than mentioning it in passing:
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html
"The "((" and "))" symbols are control operators in the KornShell, used
for an alternative syntax of an arithmetic expression command. A
conforming application cannot use "((" as a single token (with the
exception of the "$((" form for shell arithmetic).
On some implementations, the symbol "((" is a control operator; its use
produces unspecified results. Applications that wish to have nested
subshells, such as:
((echo Hello);(echo World))
must separate the "((" characters into two tokens by including white
space between them. Some systems may treat these as invalid arithmetic
expressions instead of subshells."
POSIX also states:
"Arithmetic expansions have precedence over command substitutions. That
is, if the shell can parse an expansion beginning with "$((" as an
arithmetic expansion then it will do so. It will only parse the
expansion as a command substitution (that starts with a subshell) if it
determines that it cannot parse the expansion as an arithmetic
expansion. If the syntax is valid for neither type of expansion, then it
is unspecified what kind of syntax error the shell reports.
How well the shell performs this determination is a quality of
implementation issue. Current shell implementations use heuristics. In
particular, the shell need not evaluate nested expansions when
determining whether it can parse an expansion beginning with "$((" as an
arithmetic expansion. For example:
$((a $op b))
is always an arithmetic expansion if "$op" expands to, say, '+', but if
"$op" expands to '(' then the shell might still parse the expansion as
an arithmetic expansion (resulting in a syntax error due to unbalanced
parentheses) or it might perform a command substitution.
This standard requires that conforming applications always separate the
"$(" and '(' with white space when a command substitution starts with a
subshell. This is because implementations may support extensions in
arithmetic expressions which could result in the shell parsing the input
as an arithmetic expansion even though a minimally conforming shell
would not. For example, many shells support arrays with the array index
(which can be an expression) in square brackets. Therefore, the presence
of "myfile[0-9]" within an expansion beginning "$((" is no guarantee
that it will be parsed as a command substitution.
The ambiguity is not restricted to the simple case of a single subshell.
More complicated ambiguous cases are possible (even with just the
standard shell syntax), such as:
$(( cat < If `((` is a bash-specific thing, why not allow it to
> handle multiple arithmetic expressions instead of just one? Thanks.
Historical practice, and the fact that right now, (()) and $(()) share
code, and we can't change how $(()) operates, so it does not make sense
to change how (()) operates. The above quotes from POSIX demonstrate
ambiguous situations where lexical analysis, rather than parsing alone,
is needed to decide between arithmetic or command substitution; so since
we are already relegated to a lexical decision, complicating the parser
isn't going to buy us any benefit.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
