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 behavio
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,
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
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 i
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?
-
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_LI
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 w
