Skip to content
Snippets Groups Projects
  1. Nov 17, 2014
  2. Oct 30, 2014
  3. Oct 28, 2014
  4. Oct 27, 2014
  5. Oct 08, 2014
  6. Oct 07, 2014
  7. Oct 06, 2014
  8. Oct 03, 2014
  9. Oct 02, 2014
    • Herbert Xu's avatar
      [ERROR] Set exitstatus in onint · b4ce4120
      Herbert Xu authored
      
      Currently the exit status when we receive SIGINT is set in evalcommand
      which means that it doesn't always get set.  For example, if you press
      CTRL-C at the prompt of an interactive dash, the exit status is not
      set to 130 as it is in many other Bourne shells.
      
      This patch fixes this by moving the setting of the exit status into
      onint which also simplifies evalcommand.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b4ce4120
    • Herbert Xu's avatar
      [TRAP] Make sure evalskip is zero before running traps · d28c13e7
      Herbert Xu authored
      
      As it is if dotrap is called with evalskip set to a nonzero value,
      it'll try to execute any set traps.  The result is that the first
      command in the first set trap will be executed while the rest of
      the trap will be silently ignored due to evalskip.  This is highly
      counterintuitive, even though both bash and ksh exhibit a similar
      behaviour.
      
      This patch fixes it by skipping trap processing if evalskip is set
      on entry.  It also adds a dotrap call to the top of evaltree to
      ensure that
      
      	while continue; do
      		continue;
      	done
      
      has a chance of running traps.
      
      Finally the pendingsigs check is moved into dotrap for compactness.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d28c13e7
    • Herbert Xu's avatar
      [EVAL] Fix use-after-free in dotrap/evalstring · 6c3f73bc
      Herbert Xu authored
      
      The function dotrap calls evalstring using the stored trap string.
      If evalstring then unsets that exact trap string then we will end
      up using freed memory.
      
      This patch fixes it by making evalstring always duplicate the string
      before using it.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6c3f73bc
  10. Sep 29, 2014
    • Herbert Xu's avatar
      [PARSER] Add nlprompt/nlnoprompt helpers · 6df87cf1
      Herbert Xu authored
      
      This patch adds the nlprompt/nlnoprompt helpers to isolate code
      dealing with newlines and prompting.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6df87cf1
    • Herbert Xu's avatar
      [PARSER] Handle backslash newlines properly after dollar sign · ef91d3d6
      Herbert Xu authored
      On Tue, Aug 26, 2014 at 12:34:42PM +0000, Eric Blake wrote:
      > On 08/26/2014 06:15 AM, Oleg Bulatov wrote:
      > > Hi!
      > > 
      > > While playing with sh generators I found that dash and bash have different
      > > interpretations for <slash><newline> sequence.
      > > 
      > > $ dash -c 'EDIT=xxx; echo $EDIT\
      > >> OR'
      > > xxxOR
      > 
      > Buggy.
      > 
      > > $ bash -c 'EDIT=xxx; echo $EDIT\
      > > OR'
      > > /usr/bin/vim
      > 
      > Correct behavior.
      > 
      > > 
      > > $ dash -c 'echo "$\
      > > (pwd)"'
      > > $(pwd)
      > > 
      > > Is it undefined behaviour in POSIX?
      > 
      > No, it's well-defined, and dash is buggy.  POSIX says:
      > 
      > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03
      > 
      > "the shell shall break its input into tokens by applying the first
      > applicable rule below to the next character in its input"
      > 
      > Rule 4 covers backslash handling, while rule 5 covers locating the end
      > of a word to be subject to $ expansion.  Therefore, rule 4 should happen
      > first.  Rule 4 defers to the section on quoting, with the caveat that
      > <newline> joining is the only substitution that happens immediately as
      > part of the parsing:
      > 
      > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
      
      
      > 
      > "If a <newline> follows the <backslash>, the shell shall interpret this
      > as line continuation. The <backslash> and <newline> shall be removed
      > before splitting the input into tokens. Since the escaped <newline> is
      > removed entirely from the input and is not replaced by any white space,
      > it cannot serve as a token separator."
      > 
      > So the fact that dash is treating the elided backslash-newline as a
      > token separator, and parsing your input as if ${EDIT}OR instead of
      > ${EDITOR} is a bug in dash.
      
      I agree.  This patch should resolve this problem and similar ones
      affecting blackslash newlines after we encounter a dollar sign.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ef91d3d6
    • Herbert Xu's avatar
      [INPUT] Kill pgetc_macro · 339b9c07
      Herbert Xu authored
      
      pgetc_macro is identical to pgetc except that it's a macro and
      pgetc isn't.  Since there is very little performance difference
      on modern systems it's time to kill pgetc_macro.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      339b9c07
  11. Sep 28, 2014
    • Herbert Xu's avatar
      [BUILTIN] Correctly handle test ! ! = ! · 4f7e4c82
      Herbert Xu authored
      
      This patch adds a special case in testcmd for the 4-argument
      expression beginning with a !.  Without this ! ! = ! is deemed
      a syntax error, which breaks POSIX.
      
      Note that this special case does not extend down into subexpressions
      so if ! ! = ! is used inside parentheses then a syntax error will
      still occur as before.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4f7e4c82
  12. Sep 26, 2014
    • Herbert Xu's avatar
      Release 0.5.8. · f21016a1
      Herbert Xu authored
    • Jonathan Nieder's avatar
      [MAN] Clarify "trap '' signals" syntax in manual page · 580a7aed
      Jonathan Nieder authored
      
      When the manpage states
      
      | <action> may be null, which cause the specified signals to be ignored.
      
      it is not immediately obvious what it means for an action to be
      null.  Clarify by explicitly referring to an empty string, as
      opposed to a NULL pointer or the string "null".
      
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      580a7aed
    • Adam Buchbinder's avatar
      [MAN] 0 and EXIT both work for exit traps · 66e922a2
      Adam Buchbinder authored
      
      I saw a discussion in which there was some confusion over whether or not
      you can use a symbolic name, since the manpage doesn't specifically say so.
      
      Signed-off-by: default avatarAdam Buchbinder <adam.buchbinder@gmail.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      66e922a2
    • Herbert Xu's avatar
      [MAN] Change characters for printf precision to bytes · 012222e3
      Herbert Xu authored
      
      On Sun, Mar 09, 2014 at 11:11:43AM +0000, Jeroen van Dijke wrote:
      > 
      > There seems to be a bug in the dash man page, at least in 0.5.7. It reads:
      > 
      >             Precision:
      >                     An optional period, `.', followed by an optional digit string giving a precision which specifies the number of digits to appear after the decimal point, for e and f formats, or the maximum number of *characters* to be printed from a string (b and s for-
      >                     mats); if the digit string is missing, the precision is treated as zero;
      > 
      > dash behaves cuts to the number of bytes
      > 
      > $ length=10; printf "%.${length}s\n" "eeeeeeeeeeeeeeeeeeeeeeeee"
      > eeeeeeeeee
      > $ length=10; printf "%.${length}s\n" "ëëëëëëëëëëëëëëëëëëëëëëëëë”
      > ëëëëë
      > 
      > 
      > The  POSIX specification (2008) says:
      > 
      > precision Gives the minimum number of digits to appear for the d, o, i, u, x, or X conversion specifiers (the field is padded with leading zeros), the number of digits to appear after the radix character for the e and f conversion specifiers, the maximum number of significant digits for the g conversion specifier; or the maximum number of *bytes* to be written from a string in the s conversion specifier. The precision shall take the form of a ( '.' ) followed by a decimal digit string; a null digit string is treated as zero.
      > 
      > So it seems to me that “characters” should be changed to “bytes”.
      
      Indeed and this patch makes that change.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      012222e3
    • Harald van Dijk's avatar
      [JOBS] Fix off-by-one error for multiple of four job numbers · 4c44561d
      Harald van Dijk authored
      
      On 29/07/13 23:44, Luigi Tarenga wrote:
      > hi list,
      > while writing a script to execute parallel ssh command on many host I found
      > a strange behavior of dash. I can replicate it with a very simple script but
      > didn't find any documentation about dash or POSIX that can explain it.
      > 
      > tested on centos 6.4 (dash 0.5.5.1) and wih dash compiled from source (0.5.7)
      > the following script reports error:
      > 
      > #!/bin/dash
      > 
      > sleep 3 &
      > sleep 3 &
      > sleep 3 &
      > sleep 3 &
      > 
      > #/bin/true
      > jobs -l
      > 
      > wait %1
      > wait %2
      > wait %3
      > wait %4
      > 
      > [vortex@lizard ~]$ ./dash-0.5.7/src/dash test.sh
      > [4] + 4569 Running
      > [3] - 4568 Running
      > [2]   4567 Running
      > [1]   4566 Running
      > prova: 14: wait: No such job: %4
      > [vortex@lizard ~]$ echo $?
      > 2
      
      Yes, this looks like a bug to me. The number of allocated jobs is always
      kept as a multiple of four, and the first check in considering whether
      the job number is valid is "if it's greater than or equal to the number
      of allocated job, it's invalid". That doesn't look right. That would
      only be right if jobs were zero-based, but they aren't. If it's exactly
      equal to the number of available jobs, it can still be valid. It works
      when adding /bin/true, because four more more jobs end up allocated
      internally.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4c44561d
    • Herbert Xu's avatar
      [BUILTIN] Set command -p path to /usr/sbin:/usr/bin:/sbin:/bin · 842050da
      Herbert Xu authored
      
      Exclude /usr/local from command -p PATH.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      842050da
Loading