summary refs log tree commit diff
path: root/rc.d/calico.in
diff options
context:
space:
mode:
authorJune McEnroe <june@causal.agency>2020-08-27 17:21:05 -0400
committerJune McEnroe <june@causal.agency>2020-08-27 17:21:05 -0400
commit40a3500351f9fe552c335b6ff213f0633749ade8 (patch)
tree81a58690c16210acc096cf6c2aa34ebbd93f8426 /rc.d/calico.in
parentcontrib/palaver: Use pounce's XDG directory (diff)
downloadpounce-40a3500351f9fe552c335b6ff213f0633749ade8.tar.gz
pounce-40a3500351f9fe552c335b6ff213f0633749ade8.zip
contrib/palaver: Fix database search and creation
Diffstat (limited to 'rc.d/calico.in')
0 files changed, 0 insertions, 0 deletions
 

generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-10-01 17:22:38 +0000


 


>2018-04-02builtin: Fix echo performance regressionHerbert Xu

The commit d6c0e1e2ffbf7913ab69d51cc794d48d41c8fcb1 ("[BUILTIN]
Handle embedded NULs correctly in printf") caused a performance
regression in the echo built-in because every echo call now goes
through the printf %b slow path where the string is always printed
twice to ensure the space padding is correct in the presence of
NUL characters.  In fact this regression applies to printf %b as
well.

This is easily fixed by making printf %b take the fast path when
no precision/field width modifiers are present.

This patch also changes the second strchurnul call to strspn which
generates slightly better code.

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



2018-04-02expand: Fix ghost fields with unquoted $@/$*Herbert Xu

Harald van Dijk <harald@gigawatt.nl> wrote:
> On 22/03/2018 22:38, Martijn Dekker wrote:
>> Op 22-03-18 om 20:28 schreef Harald van Dijk:
>>> On 22/03/2018 03:40, Martijn Dekker wrote:
>>>> This patch fixes the bug that, given no positional parameters, unquoted
>>>> $@ and $* incorrectly generate one empty field (they should generate no
>>>> fields). Apparently that was a side effect of the above.
>>>
>>> This seems weird though. If you want to remove the recording of empty
>>> regions because they are pointless, then how does removing them fix a
>>> bug? Doesn't this show that empty regions do have an effect? Perhaps
>>> they're not supposed to have any effect, perhaps it's a specific
>>> combination of empty regions and something else that triggers some bug,
>>> and perhaps that combination can no longer occur with your patch.
>>
>> The latter is my guess, but I haven't had time to investigate it.
>
> Looking into it again:
>
> When IFS is set to an empty string, sepc is set to '\0' in varvalue().
> This then causes *quotedp to be set to true, meaning evalvar()'s quoted
> variable is turned on. quoted is then passed to recordregion() as the
> nulonly parameter.
>
> ifsp->nulonly has a bigger effect than merely selecting whether to use
> $IFS or whether to only split on null bytes: in ifsbreakup(), nulonly
> also causes string termination to be suppressed. That's correct: that
> special treatment is required to preserve empty fields in "$@"
> expansion. But it should *only* be used when $@ is quoted: ifsbreakup()
> takes nulonly from the last IFS region, even if it's empty, so having an
> additional zero-length region with nulonly enabled causes confusion.
>
> Passing quoted by value to varvalue() and not attempting to modify it
> should therefore, and in my quick testing does, also work to fix the
> original $@ bug.

You're right.  The proper fix to this is to ensure that nulonly
is not set in varvalue for $*.  It should only be set for $@ when
it's inside double quotes.

In fact there is another bug while we're playing with $@/$*.
When IFS is set to a non-whitespace character such as :, $*
outside quotes won't remove empty fields as it should.

This patch fixes both problems.

Reported-by: Martijn Dekker <martijn@inlv.org>
Suggested-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>



2018-04-02parser: Allow newlines within parameter substitutionHerbert Xu

On Fri, Mar 16, 2018 at 11:27:22AM +0800, Herbert Xu wrote:
> On Thu, Mar 15, 2018 at 10:49:15PM +0100, Harald van Dijk wrote:
> >
> > Okay, it can be trivially modified to something that does work in other
> > shells (even if it were actually executed), but gets rejected at parse time
> > by dash:
> >
> >   if false; then
> >     : ${$+
> >   }
> >   fi
>
> That's just a bug in dash's parser with ${} in general, because
> it bombs out without the if clause too:
>
> 	: ${$+
> 	}

This patch fixes the parsing of newlines with parameter substitution.

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



2018-04-02expand: Fix bugs with words connected to the right of $@Herbert Xu

On Sun, Mar 04, 2018 at 12:44:59PM +0100, Harald van Dijk wrote:
>
> command:      set -- a ""; space=" "; printf "<%s>" "$@"$space
> bash:         <a><>
> dash 0.5.8:   <a>< >
> dash 0.5.9.1: <a>< >
> dash patched: <a><>

This is actually composed of two bugs.  First of all our tracking
of quotemark is wrong so anything after "$@" becomes quoted.  Once
we fix that then the problem is that the first space character
after "$@" is not recognised as an IFS.

This patch fixes both.

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



2018-03-25Revert "[BUILTIN] Remove unnecessary restoration of format string in printf"Herbert Xu

This reverts commit 7bb413255368e94395237d789f522891093c5774.

The commit breaks printf with more than argument.

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



2018-03-22parser: Fix backquote support in here-document EOF markHerbert Xu