| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
There are some remaining stat/readdir calls in dash that may lead
to spurious EOVERFLOW errors on 32-bit platforms. This patch changes
them (as well as open(2)) to use the explicit large file API.
Reported-by: Tatsuki Sugiura <sugi@nemui.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
| |
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to POSIX.1-2008 we should remove newlines only at the end of
the substitution. Newlines-only substitions causes dash to remove
newlines before beggining of the substitution. The following code:
cat <<END
1
$(echo "")
2
END
prints "1<newline>2" instead of expected "1<newline><newline>2".
This patch fixes trailing newlines processing in backquote expanding.
Signed-off-by: Nikolai Merinov <n.merinov@inango-systems.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
| |
Due to a double decrement in argstr we may miss field separators
at the end of a word in certain situations.
Reported-by: Martijn Dekker <martijn@inlv.org>
Fixes: 3cd538634f71 ("expand: Do not reprocess data when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are doing VSLENGTH expansion, the closing brace is currently
not removed in evalvar. This causes the caller argstr to terminate
prematurely as it would interpret the closing brace as one that
belongs to a parameter expansion at the outer level.
This patch fixes it.
Reported-by: Martijn Dekker <martijn@inlv.org>
Fixes: 3cd538634f71 ("expand: Do not reprocess data when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit 3cd538634f71538370f5af239f342aec48b7470b broke parameter
expansion in multiple ways because the EXP_DISCARD flag wasn't set
or tested for various cases:
$ src/dash -c 'var=; echo ${var:+nonempty}'
nonempty
$ src/dash -u -c 'unset foo bar; echo ${foo+${bar}}'
dash: 1: bar: parameter not set
$ src/dash -c 'foo=bar; echo ${foo=BUG}; echo $foo'
barBUG
bar
$
This patch fixes them by introducing a new discard variable that
tracks whether the extra word should be discarded or not when it
is parsed.
Reported-by: Martijn Dekker <martijn@inlv.org>
Fixes: 3cd538634f71 ("expand: Do not reprocess data when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Martijn Dekker <martijn@inlv.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
| |
The minus sign generated from arithmetic expansion is currently
unquoted which causes anomalies when the result is used in where
the quoting matters.
This patch fixes it by explicitly calling memtodest on the result
in cvtnum.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently various paths will reprocess data when performing word
expansion. For example, expari will skip backwards looking for
the start of the arithmetic expansion, while evalvar will skip
unexpanded words manually.
This is cumbersome and error-prone. This patch fixes this by
making word expansions proceed in a linear fashion. This means
changing argstr and the various expansion functions such as expari
and subevalvar to return the next character to be expanded.
This is inspired by similar code from FreeBSD. However, we take
things one step further and completely remove the manual word
skipping in evalvar. This is accomplished by introducing a new
EXP_DISCARD flag that tells argstr to only parse and not produce
any actual expansions.
Incidentally, argstr will now always NUL-terminate the expansion
unless the EXP_WORD flag is set. This is because all but one
caller of argstr wants the result to be NUL-termianted.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
| |
When we are trimming an unset variable in evalvar, any embedded
command substitution that should have been skipped are not. This
can cause them to be evaluated later should there be other command
substitutions in the same input word.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function arguments syntax and quotes are both derived from
the expansion flags. As syntax is only used by memtodest we do
not need to maintain it outside of the function at all.
The only place that uses something other than BASESYNTAX or DQSYNTAX
is exptilde. However in that case DQSYNTAX has exactly the same
effect as SQSYNTAX.
This patch merges these two arguments into a single flags. The
macro QUOTES_KEEPNUL has been renamed to EXP_KEEPNUL in order
to keep the namespace separate.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
| |
Currently if HOME is set to empty tilde expansion will fail, i.e.,
it will remain as a literal tilde. This patch changes it to
return the empty string as required by POSIX.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously reset was called after exitshell. This was changed
so that it was called before exitshell because certain state needed
to be reset in order for the EXIT trap to work.
However, this caused issues because certain other states (such
as local variables) should not be reset. This patch fixes this
by creating a new function exitreset that is called prior to
exitshell and moving reset back to its original location.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Mon, Mar 26, 2018 at 07:25:20PM +0200, Martijn Dekker wrote:
> Op 26-03-18 om 17:38 schreef Harald van Dijk:
> > And not by dash 0.5.4. Like I wrote, dash 0.5.5 had some bugs that were
> > fixed in 0.5.6, which mostly restored the behaviour to match <0.5.5.
>
> Ah, sorry. dash 0.5.4 and earlier don't compile on my system, so they
> are not included in my conveniently accessible arsenal of test shells.
>
> > As for my patches, that was by accident and doesn't work reliably. When
> > the shell sees no metacharacters, pathname expansion is bypassed, and
> > backslash isn't considered a metacharacter. Which got me to my original
> > example of /de\v: there are no metacharacters in there, so the shell
> > doesn't look to see if it matches anything. Which seems highly
> > desirable: the shell shouldn't need to hit the file system for words not
> > containing metacharacters. The only way then to get consistent behaviour
> > is if the backslash is taken as quoted, so I'm not tempted to argue for
> > the behaviour you're hoping for, sorry. :)
Here is a better example:
a="/*/\nullx" b="/*/\null"; printf "%s\n" $a $b
dash currently prints
/*/\nullx
/*/\null
bash prints
/*/\nullx
/dev/null
You may argue the bash behaviour is inconsistent but it actually
makes sense. What happens is that quote removal only applies to
the original token as seen by the shell. It is never applied to
the result of parameter expansion.
Now you may ask why on earth does the second line say "/dev/null"
instead of "/dev/\null". Well that's because it is not the quote
removal step that removed the backslash, but the pathname expansion.
The fact that the /de\v does not become /dev even though it exists
is just the result of the optimisation to avoid unnecessarily
calling stat(2). I have checked POSIX and I don't see anything
that forbids this behaviour.
So going back to dash yes I think we should adopt the bash behaviour
for pathname expansion and keep the existing case semantics.
This patch does exactly that. Note that this patch does not work
unless you have already applied
https://patchwork.kernel.org/patch/10306507/
because otherwise the optimisation mentioned above does not get
detected correctly and we will end up doing quote removal twice.
This patch also updates expmeta to handle naked backslashes at
the end of the pattern which is now possible.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
| |
It's been a while since we disabled glob(3) support by default.
It appears to be working now, however, we have to change our
code to detect the no-match case correctly.
In particular, we need to test for GLOB_NOMAGIC | GLOB_NOCHECK
instead of GLOB_MAGCHAR.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native version of expandmeta allocates a buffer that may be
overrun for two reasons. First of all the size is 1 byte too small
but this is normally hidden because the minimum size is rounded
up to 2048 bytes. Secondly, if the directory level is deep enough,
any buffer can be overrun.
This patch fixes both problems by calling realloc when necessary.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without a stack of syntaxes we cannot correctly these two cases
together:
"${a#'$$'}"
"${a#"${b-'$$'}"}"
A recursive parser also helps in some other corner cases such
as nested arithmetic expansion with paratheses.
This patch adds a syntax stack allocated from the stack using
alloca. As a side-effect this allows us to remove the naked
backslashes for patterns within double-quotes, which means that
EXP_QPAT also has to go.
This patch also fixes removes any backslashes that precede right
braces when they are present within a parameter expansion context,
and backslashes that precede double quotes within inner double
quotes inside a parameter expansion in a here-document context.
The idea of a recursive parser is based on a patch by Harald van
Dijk.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Op 29-03-17 om 20:02 schreef Martijn Dekker:
> Bug: if either the 'nolog' or the 'debug' option is set, trying to
> expand "$-" silently aborts parsing of an entire argument.
>
> $ dash -o nolog -c 'set -fuC; echo "|$- are the options|"; \
> set +o nolog; echo "|$- are the options|"'
> |
> |uCf are the options|
> $ dash -o debug -c 'set -fuC; echo "|$- are the options|"; \
> set +o debug; echo "|$- are the options|"'
> |
> |uCf are the options|
This turned out to be easy to fix. The routine producing the "$-"
expansion failed to skip options for which there is no option letter,
but only a long-form name. In dash, 'nolog' and 'debug' are currently
the only two such options. Patch below.
- Martijn
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Ugh; forgot to attach patch - apologies, I need more coffee ]
Dear all,
Attached is a trivial patch that removes the assumption that fnmatch.h
is available - the configure script already checks for fnmatch(3) and
supplies its own implementation if necessary, but fnmatch.h is always
included.
Let me know what you think.
Regards,
Rink
Do not assume we can include fnmatch.h
Signed-off-by: Rink Springer <rink@rink.nu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
| |
When there is an unmatched left square bracket in patterns, pmatch
will behave strangely and exhibit undefined behaviour. This patch
(based on Harld van Dijk's original) fixes this by treating it as
a literal left square bracket.
Reported-by: Olof Johansson <olof@ethup.se>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The read built-in does not handle trailing IFS white spaces in
the right way, when there are more fields than variables. Part
of the problem is that this case is handled outside of ifsbreakup.
Harald van Dijk wrote a patch to fix this by moving the magic
into ifsbreakup itself.
This patch further reorganises the ifsbreakup loop by having only
one loop over the whole string.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Harald van Dijk <harald@gigawatt.nl>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit 3c06acdac0b1ba0e0acdda513a57ee6e31385dce ([EXPAND]
Split unquoted $@/$* correctly when IFS is set but empty) broke
the case where $@ is in quotes and EXP_FULL is false.
In that case we should still emit IFS as field splitting is not
performed.
Reported-by: Juergen Daubert <jue@jue.li>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
| |
This patch makes a small optimisation by using the same value for
quoted between evalvar and varvalue by eliminating nulonly and
passing along quoted instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
| |
Currently VSLENGTH and VSTRIM* are field-split even within quotes.
This is obviously wrong. This patch fixes that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
| |
Currently we do not field-split $@/$* when it isn't quoted and IFS
is set but empty. This is obviously wrong. This patch fixes this.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here's another bug bisecting to f42e443bb ([EXPAND] Fix
ifsfirst/ifslastp leak, 2010-09-08). It was found with the following
test case, based on the configure script for Tracker:
dash -x -c '
<<-_ACEOF
$@
_ACEOF
exec
' - abcdefgh
+
+ exec �a
exec: 1: : Permission denied
The missing ifsfree call is in expandarg when it returns to openhere
during here document expansion.
Reported-by: Aurelien Jarno <aurel32@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Solaris lacks paths.h and the various _PATH_* #defines.
Check for them in configure.ac and fall back on the
usual suspects when they are missing.
- Older Solaris lacks isblank(), and versions that have it
use a macro. Check for the declaration in configure.ac
and fall back on a naive version when missing.
- Older Solaris does not support %jd (intmax_t) in format
strings, but it does support the PRIdMAX macro from inttypes.h.
Do a configure check for PRIdMAX and use it in the code.
If it doesn't exist, define it to "lld" when sizeof(long long)
equals sizeof(intmax_t) as this is more likely to work on
older systems. Otherwise, use "jd" and hope for the best.
- Older Solaris lacks stdint.h, but inttypes.h provides the
same types and works on all platforms I've tried dash on,
so just use it instead.
- Older Solaris doesn't like it when vsnprintf() is passed
a NULL buffer (in violation of the POSIX spec, of course).
Pass a 1-byte dummy buffer instead.
- Solaris lacks tempfile and mktemp programs. Fall back on a
"good-enough" custom function in mkbuiltins.
Signed-off-by: Brian Koropoff <bkoropoff@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new read(1) implementation incorrectly assumes that ifsbreakup
ignores characters escaped by CTLESC. As such it fails to handle
backslashes except for escaping newlines.
This patch makes it use recordregion for every part that isn't
escaped by a backslash.
Reported-by: Jilles Tjoelker <jilles@stack.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A tilde expansion generates a valid pathname. Splitting it using IFS
either leaves it unchanged or changes it to something unintended.
This fixes FreeBSD sh test expansion/tilde1.0 and does not change the
outcome of the other tests.
This fixes Debian bug #601096.
Example:
IFS=m HOME=/tmp; printf "%s\n" ~
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit f42e443bb511ed3224f09b4fcf0772438ebdbbfa
[EXPAND] Fix ifsfirst/ifslastp leak
revealed yet another ifsfirst/ifslastp leak in casematch.
Previously it was hidden because ifsfirst/ifslastp was cleared
unconditionally on entry (which caused the leakage of those
entries).
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it stands expandarg may return with a non-NULL ifslastp which
then confuses any subsequent ifsbreakup user that doesn't clear
it directly.
What's worse, if we get interrupted before we hit ifsfree in
expandarg we will leak memory.
This patch fixes this by always calling ifsfree in expandarg
thus ensuring that ifslastp is always NULL on the normal path.
It also adds an ifsfree call to the RESET path to ensure that
memory isn't leaked.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In other ash variants, a partial implementation of ksh-like cmd >file*
adds and removes CTLESC bytes ('\x81') in redirection filenames,
preserving 8-bit transparency. Long ago, dash removed the code to add
the CTLESC bytes, but not the code to remove them, causing corruption of
filenames containing CTLESC. This commit removes the code to remove the
CTLESC bytes.
The CTLESC byte occurs frequently in UTF-8 encoded non-Latin text.
This bug has been reported various times to Ubuntu and Debian (e.g.
Launchpad Ubuntu #422298). This patch is the same as the one submitted
by Alexander Korolkov in Ubuntu #422298.
Signed-off-by: Jilles Tjoelker <jilles@stack.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I try to split fields by tabs, dash doesn't honour multiple tabs
between fields as whitespace (at least that's how I interpret [1],
please correct me if I'm wrong).
#!/bin/sh
# "1\t2\t\t3"
TESTSTRING="1 2 3"
# only "\t"
IFS=" "
echo "$TESTSTRING" | while read p1 p2 p3; do
echo "p1=${p1}, p2=${p2}, p3=${p3}"
done
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change
[EXPAND] Do not quote back slashes in parameter expansions outside quotes
broke quote removal after parameter expansion. This is because
its effecte extended beyond that of quoted patterns.
This patch fixes this by limiting the change to just quoted
patterns.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in January an attempt was made to fix the interpretation of
quoted slashes in expmeta. However, this only fixed those cases
where the quoted slash is at the front of the word. The case of
non-leading slashes caused the previous directory part to gain a
back slash suffix which causes subsequent pattern matches to fail.
This patch fixes this by removing the back slash in that case.
Thanks to Romain Tartière fox reporting this bug.
Test case:
echo /*"/null"
Old result:
/*/null
New result:
/dev/null
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
klibc does not have mempcpy, so system.h must be included where this is used
to provide the replacement. glob.h doesn't exist, so we need to guard this
include with the HAVE_GLOB definition. Finally, klcc didn't like the syntax
of the main definition in mksignames, and the resulting program segfaulted
when trying to dereference any part of the argv array. Updating the main
function definition solved the problem.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change
[EXPAND] Do not quote back slashes in parameter expansions outside quotes
triggered a latent bug in expmeta where the forward slashes when preceded
by a blackslash weren't recognised as directory separators. This was hidden
because a work-around was put in place for glob(3) which meant that we never
had any backslashes immediately before forward slashes.
This patch fixes the metaflag loop to recognise forward slashes even when
they follow a backslash.
Thanks to Daniel Hahler for reporting this problem.
Test case:
echo "/"root*
Old result:
/root*
New result:
/root
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we always expanded here-documents in a subshell. This is
contrary to the POSIX specification and how other shells behave. What's
more this slows down many expansions due to the extra fork (however, it
must be said that it is possible for it speed up certain expansions by
running it simultaneously with the command on two CPUs).
This patch move the expansion into the current shell environment.
Test case:
unset a
cat <<- EOF > /dev/null
${a=NOT}
EOF
echo ${a}BAD
Old result:
BAD
New result:
NOTBAD
|
|
|
|
|
|
|
|
|
|
|
| |
The herefd hack goes back more than a decade. it limits the amount of
memory we have to allocate when expanding here-documents by writing the
result out from time to time. However, it's no longer safe because the
stack is used to place intermediate results too and there we certainly
don't want to write them out should we be short on memory.
In any case, with today's computers we can afford to keep the entire
result in memory and write them out at the end.
|
|
|
|
|
|
|
|
| |
Debian's libc6 as of 2.6.1-6 has working glob(3)/fnmatch(3) support.
This patch adds the options --enable-glob and --enable-fnmatch to
the configure script. By default glob(3) and fnmatch(3) are still
unused. However, on distros where the glibc is known to work you
may enable these options.
|
|
|
|
| |
The case where the expansion isn't quoted is the norm.
|
|
|
|
|
| |
This patch adds assignment operator support in arithmetic expansions. It
also changes the type used to intmax_t.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Wed, Apr 11, 2007 at 01:24:21PM -0700, Micah Cowan wrote:
> Package: dash
> Version: 0.5.3-3
>
> Bug first reported against Ubuntu at
> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/105634
> by Paul Smith
>
> The description and some comments from that bug report follow.
>
> -----
>
> This operation fails on Ubuntu:
>
> $ /bin/sh -c 'if false; then d="${foo/bar}"; fi'
> /bin/sh: Syntax error: Bad substitution
>
> When used with other POSIX shells it succeeds. While semantically the
> variable reference ${foo/bar} is not valid, this is not a syntax error
> according to POSIX, and since the variable assignment expression is
> never invoked (because it's within an "if false") it should not be seen
> as an error.
>
> I ran into this because after restarting my system I could no longer log
> in. It turns out that the problem was (a) I had edited .gnomerc to
> source my .bashrc file so that my environment would be set properly, and
> (b) I had added some new code to my .bashrc WITHIN A CHECK FOR BASH!
> that used bash's ${var/match/sub} feature. Even though this code was
> within a "case $BASH_VERSION; in *[0-9]*) ... esac (so dash would never
> execute it since that variable is not set), it still caused dash to
> throw up.
>
> -----
>
> FYI, some relevant details from POSIX:
>
> Section 2.3, Token Recognition:
>
> 5. If the current character is an unquoted '$' or '`', the shell shall
> identify the start of any candidates for parameter expansion ( Parameter
> Expansion), command substitution ( Command Substitution), or arithmetic
> expansion ( Arithmetic Expansion) from their introductory unquoted
> character sequences: '$' or "${", "$(" or '`', and "$((", respectively.
> The shell shall read sufficient input to determine the end of the unit
> to be expanded (as explained in the cited sections).
>
> Section 2.6.2, Parameter Expansion:
>
> The format for parameter expansion is as follows:
>
> ${expression}
>
> where expression consists of all characters until the matching '}'. Any
> '}' escaped by a backslash or within a quoted string, and characters in
> embedded arithmetic expansions, command substitutions, and variable
> expansions, shall not be examined in determining the matching '}'.
>
> [...]
>
> The parameter name or symbol can be enclosed in braces, which are
> optional except for positional parameters with more than one digit or
> when parameter is followed by a character that could be interpreted as
> part of the name. The matching closing brace shall be determined by
> counting brace levels, skipping over enclosed quoted strings, and
> command substitutions.
>
> ---
>
> In addition to bash I've checked Solaris /bin/sh and ksh and they don't
> report an error.
>
> -----
> Micah Cowan:
>
> The applicable portion of POSIX is in XCU 2.10.1:
>
> "The WORD tokens shall have the word expansion rules applied to them
> immediately before the associated command is executed, not at the time
> the command is parsed."
>
> This seems fairly clear to me.
This patch moves the error detection to expansion time.
Test case:
if false; then
echo ${a!7}
fi
echo OK
Old result:
dash: Syntax error: Bad substitution
New result:
OK
|
|
|
|
|
|
|
|
| |
This patch gets rid of the stack mark tracking hack by allocating a little
bit of stack memory if we're at risk of planting a stack mark which may be
grown later. To do this a new function pushstackmark is added which lets
the user pick a bigger amount to allocate since some users do that anyway
after setting a stack mark.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dash-0.5.3 has an issue reading some line lengths [1].
This is reproducable on amd64, but not on other arches for some reason.
$ cat bug.sh
(read line; echo "${line%%=*}") <<EOF
TITLE=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
EOF
printf "\
TITLE=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
" | (read line; echo "${line%%=*}")
$ bash bug.sh
TITLE
TITLE
$ dash bug.sh
TITLE=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TITLE
Attahced is a patch to fix the issue
Thanks
Roy
[1] http://bugs.gentoo.org/show_bug.cgi?id=180680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the parser does not recursively parse parameter expansion with respect
to quotes, we can't accurately determine quote status at parse time. This
patch works around this by moving the quote detection to run-time where we
do interpret it recursively.
Test case:
foo=\\
echo "<${foo#[\\]}>"
Old result:
<\>
New result:
<>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously code was added so that tilde expansion was carried out
parameter expansions within double quotes. This change was made
with reference the behaviour of bash at the time. Bash has since
be fixed so that this behaviour no longer occurs which is in line
with most other POSIX shells.
So this patch removes that behaviour in dash as well.
Test case:
unset a
echo "${a:-~root}"
Old result:
/root
New result:
~root
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously tilde expansion was not carried out for =?#% expansion words.
This is contrary to the POSIX specification.
Test case:
a=~root:~root
echo ${a#~root}
Old result:
/root:/root
New result:
:/root
|