[MAN] Fix typo for wait

This is a small patch to fix the paragraph about 'wait' in the dash manpage.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[EXPAND] Propagate EXP_QPAT in subevalvar

On Tue, Aug 28, 2012 at 01:27:24PM +0000, Todor Vlaev wrote:
> 
> While playing around with parameter expansion I noticed that the
> following didn't work in dash  (dash 0.5.5.1-7.4ubuntu1) as compared
> to bash even though I believe it should be POSIX-compliant:
> 
> my_str=swan; last_char="${my_str#${my_str%?}}"; echo ${last_char}
> 
> If the double quotes are removed, the last character is printed correctly.
> 
> At a quick glance through the commits after the 0.5.5.1 release I saw
> the following bug fix. Could it be related?
> 
> 0d7d66039b614b642c775432fd64aa8c11f9a64d
> [EXPAND] Fix quoted pattern patch breakage

We need to propagate EXP_QPAT in subevalvar as otherwise a nested
parameter expansion within subevalvar may be expanded incorrectly.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[BUILTIN] Use PRIdMAX instead of %j in printf

On 12/03/2012 05:59 PM, Harald van Dijk wrote:
> On 12/03/2012 08:42 AM, Roy wrote:
>> MSYS libc does not support %j[dXx] format, only %ll[dXx] is supported.
>>
>> diff --git a/src/bltin/printf.c b/src/bltin/printf.c
>> index 893295c..12ce660 100644
>> --- a/src/bltin/printf.c
>> +++ b/src/bltin/printf.c
>> @@ -319,11 +319,12 @@ mklong(const char *str, const char *ch)
>>         char *copy;
>>         size_t len;
>>
>> -       len = ch - str + 3;
>> +       len = ch - str + 4;
>>         STARTSTACKSTR(copy);
>>         copy = makestrspace(len, copy);
>> -       memcpy(copy, str, len - 3);
>> -       copy[len - 3] = 'j';
>> +       memcpy(copy, str, len - 4);
>> +       copy[len - 4] = 'l';
>> +       copy[len - 3] = 'l';
>>         copy[len - 2] = *ch;
>>         copy[len - 1] = '\0';
>>         return (copy);
> 
> The calling code uses the result to print intmax_t and uintmax_t values.
> Printing intmax_t values with %lld is wrong, this will only work if
> intmax_t is really a typedef for long long (which may be true on your
> system, but is not required by the standard).
> 
> The other patch that Jonathan linked to should work just fine.

Here's a slightly tweaked version of that patch. Regardless of whether
PRIdMAX is defined as "jd" or as "lld", the use of memcpy here, first
copying "jd"/"lld" and the null byte, and only changing the 'd' after
that, surprisingly results in slightly shorter object code than the
original byte-by-byte approach, even though memcpy is fully inlined.
Perhaps that could be a reason for applying this, even if the original
reason for it, making the code work on not-quite-conforming systems,
isn't good enough to get it in dash.

Tested with normal glibc, and with glibc hacked to not provide PRIdMAX.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[MAN] Markup fixes in manual for mandoc 1.12.1

with Aleksey we briefly discussed the mdoc compatibility of the manpage,
here's a patch that makes mandoc 1.12.1 happier and behaves correctly
against groff 1.21.  I want to include it in the staging dash-0.5.7
OpenBSD port.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[VAR] Add newline when tracing in poplocalvars

Signed-off-by: Peter Rosin <peda@lysator.liu.se>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[VAR] Initialise OPTIND after importing environment

On Sat, Mar 23, 2013 at 01:46:20AM +0000, Chris F.A. Johnson wrote:
> 
>   According to both the dash man page and the POSIX spec, "When the
>   shell is invoked, OPTIND is initialized to 1."
> 
>   However, it actually takes the value of the environment variable
>   if it exists:
> 
> $ OPTIND=4 dash -c 'echo "$OPTIND"'
> 4
> $ OPTIND=4 bash -c 'echo "$OPTIND"'
> 1
> $ OPTIND=4 ksh -c 'echo "$OPTIND"'
> 1
> $ OPTIND=4 ksh93 -c 'echo "$OPTIND"'
> 1

This patch fixes this by initialising OPTIND after importing the
environment.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[BUILTIN] Fixed argument parsing crash in test

When nexpr gets an unexpected EOI, this may cause crashes further
up the call chain because we've advanced t_wp too far.  Fix it by
checking for EOI in nexpr and only advancing t_wp if we've got more
arguments.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>