summary refs log tree commit diff
path: root/src/expand.c (follow)
Commit message (Collapse)AuthorAge
* expand: Fix trailing newlines processing in backquote expandingNikolai Merinov2020-01-20
| | | | | | | | | | | | | | | | | | | 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>
* expand: Fix double-decrement in argstrHerbert Xu2019-03-28
| | | | | | | | | 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>
* expand: Eat closing brace for length parameter expansionHerbert Xu2018-12-14
| | | | | | | | | | | | | 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>
* expand: Fix multiple issues with EXP_DISCARD in evalvarHerbert Xu2018-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: Ensure result is escaped in cvtnumHerbert Xu2018-08-29
| | | | | | | | | | | 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>
* expand: Do not reprocess data when expanding wordsHerbert Xu2018-08-29
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: Fix skipping of command substitution when trimming in evalvarHerbert Xu2018-08-29
| | | | | | | | | 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>
* expand: Merge syntax/quotes in memtodest with flagsHerbert Xu2018-08-29
| | | | | | | | | | | | | | | | 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>
* expand: Use HOME in tilde expansion when it is emptyHerbert Xu2018-08-29
| | | | | | | | 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>
* mkinit: Split reset into exitreset and resetHerbert Xu2018-05-28
| | | | | | | | | | | | | 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>
* expand: Do not quote backslashes in unquoted parameter expansionHerbert Xu2018-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: Fix glibc glob(3) supportHerbert Xu2018-04-19
| | | | | | | | | | | 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>
* expand: Fix buffer overflow in expandmetaHerbert Xu2018-04-02
| | | | | | | | | | | | 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>
* expand: Fix ghost fields with unquoted $@/$*Herbert Xu2018-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: Fix bugs with words connected to the right of $@Herbert Xu2018-04-02
| | | | | | | | | | | | | | | | | | | 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>
* parser: Add syntax stack for recursive parsingHerbert Xu2018-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: 'nolog' and 'debug' options cause "$-" to wreak havocMartijn Dekker2018-03-10
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* expand: Remove dependency on fmatch.h if it does not exitRink Springer2018-03-10
| | | | | | | | | | | | | | | | | | | | | [ 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>
* expand - Fix dangling left square brackets in patternsHerbert Xu2016-09-23
| | | | | | | | | | 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>
* builtin: Fix handling of trailing IFS white spacesHerbert Xu2016-09-02
| | | | | | | | | | | | | | | 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>
* expand: Fixed "$@" expansion when EXP_FULL is falseHerbert Xu2015-01-05
| | | | | | | | | | | | 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>
* [EXPAND] Optimise nulonly away and just use quoted as beforeHerbert Xu2014-10-08
| | | | | | | | 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>
* [EXPAND] Do not split quoted VSLENGTH and VSTRIMHerbert Xu2014-10-08
| | | | | | | 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>
* [EXPAND] Split unquoted $@/$* correctly when IFS is set but emptyHerbert Xu2014-10-08
| | | | | | | 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>
* [EXPAND] Propagate EXP_QPAT in subevalvarHerbert Xu2013-08-23
| | | | | | | | | | | | | | | | | | | | | | | 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>
* [EXPAND] Free IFS state after here document expansionJonathan Nieder2011-03-15
| | | | | | | | | | | | | | | | | | | | | | | 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>
* [SHELL] Port to SolarisBrian Koropoff2011-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* [BUILTIN] Fix backslash handling in read(1)Herbert Xu2011-03-11
| | | | | | | | | | | | 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>
* [EXPAND] Do not split the result of tilde expansionJilles Tjoelker2011-03-10
| | | | | | | | | | | | | | | 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>
* [EXPAND] Fix ifsfirst/ifslastp leak in casematchHerbert Xu2010-10-18
| | | | | | | | | | | | | 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>
* [EXPAND] Fix ifsfirst/ifslastp leakHerbert Xu2010-09-08
| | | | | | | | | | | | | | | | 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>
* [EXPAND] Fix corruption of redirections with byte 0x81Jilles Tjoelker2010-05-27
| | | | | | | | | | | | | | | | | | 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>
* [BUILTIN] Honor tab as IFS whitespace when splitting fields in readcmdStefan Potyra2009-08-11
| | | | | | | | | | | | | | | | | | | 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>
* [EXPAND] Fix quoted pattern patch breakageHerbert Xu2009-06-27
| | | | | | | | | | | | | | 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>
* [EXPAND] Fixed non-leading slash treatment in expmetaHerbert Xu2008-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [SHELL] Fixed klibc/klcc build problemsDan McGee2008-05-03
| | | | | | | | | | | | 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>
* [EXPAND] Fix slash treatment in expmetaHerbert Xu2008-05-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [EXPAND] Expand here-documents in the current shell environmentHerbert Xu2007-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [EXPAND] Removed herefd hackHerbert Xu2007-11-11
| | | | | | | | | | | 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.
* [EXPAND] Added configure --enable-glob and --enable-fnmatch optionsHerbert Xu2007-10-20
| | | | | | | | 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.
* [EXPAND] Add likely flags in expariHerbert Xu2007-10-11
| | | | The case where the expansion isn't quoted is the norm.
* [ARITH] Add assignment and intmax_t supportHerbert Xu2007-10-11
| | | | | This patch adds assignment operator support in arithmetic expansions. It also changes the type used to intmax_t.
* [PARSER] Report substition errors at expansion timeHerbert Xu2007-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MEMALLOC] Add pushstackmarkHerbert Xu2007-10-06
| | | | | | | | 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.
* [EXPAND] Refresh stack pointers after makestrspace in _rmescapesRoy Marples2007-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [EXPAND] Move parse-time quote flag detection to run-timeHerbert Xu2007-09-25
| | | | | | | | | | | | | | | | | | | | 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: <>
* [EXPAND] Do not expand tilde in parameter expansion within quotesHerbert Xu2007-09-25
| | | | | | | | | | | | | | | | | | | | | | | 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
* [EXPAND] Perform tilde expansion in all parameter expansion wordsHerbert Xu2007-09-24
| | | | | | | | | | | | | | | | | | 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
* [EXPAND] Do not quote back slashes in parameter expansions outside quotesHerbert Xu2007-09-24
| | | | | | | | | | | | | | | | Test case: a=/b/c/* b=\\ echo ${a%$b*} Old result: /b/c/* New result: /b/c/
* [EXPAND] Fixed inverted char class matchingHerbert Xu2006-10-04
| | | | | | | | The return value of ccmatch was being treated as 0 or 1 but it's actually zero or non-zero. This broke inverted character class matching. Reported by Alexander Skwar.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-15 23:12:51 +0000