Re: dash bug: double-quoted "\" breaks glob protection for next char

Op 07-03-18 om 16:29 schreef Herbert Xu: > I also didn't quite like the idea of scanning the string backwards > to find the previous syntax. So here is my attempt at the recursive > parsing using alloca. This version introduces a parsing bug: $ src/dash -c 'x=0; x=$((${x}+1))' src/dash: 1:

Re: dash tested against ash testsuite: 17 failures

On 3/7/18 7:51 AM, Herbert Xu wrote: On Wed, Mar 07, 2018 at 07:49:16AM +0100, Harald van Dijk wrote: This was wrong in the original patch, but I'm not seeing it in the updated patch that you replied to. When parsing a heredoc where part of delimiter is quoted, syntax==SQSYNTAX. Since the

Re: dash bug: double-quoted "\" breaks glob protection for next char

On 3/7/18 5:29 PM, Herbert Xu wrote: On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote: Another pre-existing dash parsing bug that I encountered now is $(( ( $(( 1 )) ) )). This should expand to 1, but gives a hard error in dash, again due to the non-recursive nature of dash's

Re: dash bug: double-quoted "\" breaks glob protection for next char

On 3/7/18 8:04 PM, Harald van Dijk wrote: On 3/7/18 5:29 PM, Herbert Xu wrote: On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote: Another pre-existing dash parsing bug that I encountered now is $(( ( $(( 1 )) ) )). This should expand to 1, but gives a hard error in dash, again

Re: dash tested against ash testsuite: 17 failures

On Wed, Mar 07, 2018 at 07:19:56PM +0100, Harald van Dijk wrote: > On 3/7/18 7:51 AM, Herbert Xu wrote: > >On Wed, Mar 07, 2018 at 07:49:16AM +0100, Harald van Dijk wrote: > >> > >>This was wrong in the original patch, but I'm not seeing it in the updated > >>patch that you replied to. When

Re: dash tested against ash testsuite: 17 failures

On 3/8/18 7:30 AM, Herbert Xu wrote: Could you please resend these patches as two separate emails please? Patchwork cannot handle two patches in one email: https://patchwork.kernel.org/patch/10264661/ Ah, didn't realise that. I'll keep that in mind for future mails. Actually, I'll

[PATCH v2] parser: Add syntax stack for recursive parsing

On Wed, Mar 07, 2018 at 08:25:07PM +, Martijn Dekker wrote: > > This version introduces a parsing bug: > > $ src/dash -c 'x=0; x=$((${x}+1))' > src/dash: 1: Syntax error: Unterminated quoted string > > It is triggered by the ${x} (with braces) within an arithmetic expression. Thanks for

Re: dash bug: double-quoted "\" breaks glob protection for next char

On Thu, Mar 08, 2018 at 01:40:32AM +0100, Harald van Dijk wrote: > > If the syntax stack is to be stored on the actual stack, then real recursion > could be used instead, as attached. I tried to avoid recursion for the cases > that unpatched dash already handled properly. It does look a lot

Re: Greater resolution in test -nt / test -ot

Op 07-03-18 om 15:46 schreef Martijn Dekker: > Op 06-03-18 om 09:19 schreef Herbert Xu: >> On Thu, Jun 22, 2017 at 10:30:02AM +0200, Petr Skočík wrote: >>> would you be willing to pull something like this? > [...] >>> I could use greater resolution in `test -nt` / `test -ot`, and st_mtim >>> field

Re: [PATCH] fix "Illegal number" on FreeBSD & macOS for x=; echo $((x))

Op 07-03-18 om 06:26 schreef Herbert Xu: > Martijn Dekker wrote: >> >>> Since base is always a constant 0 or a constant 10, never a >>> user-provided value, the only error that strtoimax will ever report on >>> glibc systems is ERANGE. Checking only ERANGE therefore preserves

Re: dash bug: double-quoted "\" breaks glob protection for next char

On Sun, Mar 04, 2018 at 10:29:25PM +0100, Harald van Dijk wrote: > > Another pre-existing dash parsing bug that I encountered now is $(( ( $(( 1 > )) ) )). This should expand to 1, but gives a hard error in dash, again due > to the non-recursive nature of dash's parser. A small generalisation of