Harald van Dijk schreef op 29-05-15 om 00:39:
A quick patch to make sure it is global, and isn't reset when it
shouldn't or doesn't need to be, is attached. You can experiment with
it, if you like.
I've been using dash with this patch since you posted it, and it works
like a charm (including
POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
${#parameter}
String Length. The length in characters of the value of parameter
shall be substituted. [...]
dash does not expand the length in characters; it expands the length in
bytes instead. That
Parke schreef op 06-07-15 om 04:18:
The man page does not say what happens if the given name corresponds
only to a function.
Neither does POSIX, as you've found out: [...] if a variable by that
name does not exist, it is unspecified whether a function by that name,
if any, shall be unset. I
Herbert Xu schreef op 13-07-15 om 08:06:
Thanks for the report. Does this patch help?
Yes, it does.
Thanks,
- M.
--
To unsubscribe from this list: send the line unsubscribe dash in
the body of a message to majord...@vger.kernel.org
More majordomo info at
I found a bug in dash that affects checking the exit status of '[' or
'test' for failure.
After feeding an illegal number to 'test -t', 'test' will not accept any
operator (or at least not -gt or -lt) for the next invocation.
Confirmed in dash 0.5.7, 0.5.8 and current git version.
$ [ -t
Unlike bash, *ksh and zsh, dash allows inheriting IFS from the environment:
$ IFS=bla dash -c "x='hela hola'; echo \$x"
he ho
This seems a bit dodgy from a security point of view. For instance, most
scripts don't bother to quote their variables in test commands such as [
$var -eq 0 ], making it
The 'trap' command in dash is not compliant with POSIX. According to the
spec, both '-' and any unsigned decimal integer should be accepted as an
argument meaning 'unset this trap'; dash only accepts '-'.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28
I did
Harald van Dijk schreef op 04-12-15 om 19:51:
> Here it is. Attached is an updated patch that ignores the complete
> terminator if only a single field remains, otherwise ignores only
> trailing IFS whitespace.
I've tested the patch and it looks like it fixes the bug nicely.
With the patch, dash
Op 28-02-17 om 00:17 schreef Martijn Dekker:
> Op 27-02-17 om 21:08 schreef Martijn Dekker:
>> Shell reserved words (a.k.a. shell keywords) such as "if" are harder to
>> fix. The single_quote() routine, if told to quote conditionally, would
>> have to iterate thr
Op 01-10-16 om 19:17 schreef Denys Vlasenko:
> ash-glob/glob2.tests:
> Evidently, dash supports \f -> ^L escape.
> This test uses \f as invalid backslash escape,
> hence differences.
The test uses the "echo" builtin, which is very very unportable and
explicitly not standardised by
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
Op 28-02-17 om 04:39 schreef Martijn Dekker:
> Op 28-02-17 om 00:17 schreef Martijn Dekker:
>> Here is a version that does that, and removes '=' and '!' from the list
>> of shell-safe characters. This should fix all the issues you were
>> reporting, hopefully making the xtr
Op 21-10-17 om 14:13 schreef Jilles Tjoelker:
[...]
> I think it is sufficiently clear that various special
> characters are active in ${param#word}, whether the outer substitution
> is within double-quotes or not.
Yes -- this came up on austin-group-l some time ago as well.
Op 27-04-18 om 17:51 schreef Herbert Xu:
On Fri, Apr 27, 2018 at 05:47:27PM +0200, Martijn Dekker wrote:
No, because step 1 doesn't merely close fd 8. It enters a curly braces block
(a compound command) that locally closes fd 8 using a redirection, just like
any other redirection would
Op 13-02-18 om 14:53 schreef Denys Vlasenko:
> $ >'\'
> $ >'\'
> $ dash -c 'echo "\*"'
> \ \
>
> The cause: uses "\\*" pattern instead of "\\\*".
Also:
$ dash -c 'case \\ab in "\*") echo BUG;; esac'
BUG
$ dash -c 'case \\a in "\?") echo BUG;; esac'
BUG
Yup. Full globbing within
Op 13-08-18 om 18:30 schreef Ron Yorston:
> Simon Ser wrote:
>> On August 13, 2018 4:22 PM, Martijn Dekker wrote:
>>> - The latest release is 0.5.10.2. I can't reproduce the bug at all in
>>> 0.5.10, 0.5.10.1 or 0.5.10.2.
>>
>> This is interesting.
Op 11-08-18 om 12:08 schreef Ron Yorston:
> - Fixing this (other than using the blunt instrument of reverting the
> faulty commit) is beyond my pay grade. Someone with a better
> understanding of the code will need to take a look.
My observations:
- The latest release is 0.5.10.2. I can't
Op 06-09-18 om 07:07 schreef Herbert Xu:
On Wed, Sep 05, 2018 at 06:21:36PM +0200, Martijn Dekker wrote:
With this patch applied, the following breakage still occurs:
$ src/dash -u -c 'unset foo bar; echo ${foo+${bar}}'
src/dash: 1: bar: parameter not set
(expected: empty line, no error
Ignore .deps and .dirstamp in all directories.
diff --git a/.gitignore b/.gitignore
index 579bd47..e349901 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,11 +13,12 @@ Makefile.in
# generated by configure
Makefile
+.deps
+.dirstamp
/config.cache
/config.h
/config.log
/config.status
Op 07-03-18 om 16:29 schreef Herbert Xu:
> I also didn't quite like the idea of scanning the string backwards
> to find the previous syntax. So here is my attempt at the recursive
> parsing using alloca.
This version introduces a parsing bug:
$ src/dash -c 'x=0; x=$((${x}+1))'
src/dash: 1:
Here's a .gitignore file for the convenience of casual git users.
- M.
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..579bd47
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,41 @@
+# .gitignore for dash
+
+# generated by autogen.sh
+Makefile.in
+/aclocal.m4
+/autom4te.cache/
Op 07-03-18 om 15:46 schreef Martijn Dekker:
> Op 06-03-18 om 09:19 schreef Herbert Xu:
>> On Thu, Jun 22, 2017 at 10:30:02AM +0200, Petr Skočík wrote:
>>> would you be willing to pull something like this?
> [...]
>>> I could use greater resolution in `test -nt` / `te
Hi,
There's been no activity on dash git since 23 Sep 2016, the 0.5.9.1
release date. Since then there have been too many patches to keep track
of, some of them fixing important bugs.
Herbert, could we have a development git branch that has these patches
applied (the ones you approve of)?
Op 07-03-18 om 06:26 schreef Herbert Xu:
> Martijn Dekker <mart...@inlv.org> wrote:
>>
>>> Since base is always a constant 0 or a constant 10, never a
>>> user-provided value, the only error that strtoimax will ever report on
>>> glibc systems is ERANGE
Op 06-03-18 om 08:45 schreef Herbert Xu:
> However, your patch also breaks here-
> document parsing when the delimiter is a single backslash.
>
> cat << "\"
> \
That is supposed to break. "\" is not a correctly quoted backslash. Try
'\' or "\\" or \\
- M.
--
To unsubscribe from
Op 19-04-18 om 12:14 schreef Herbert Xu:
Sorry, but one of the key goals of dash is to be as small as
possible. So that means no features unless absolutely necessary.
As such I cannot accept this patch as it is.
Would you accept it if it were a configure option, disabled by default
(like
Op 25-03-18 om 22:56 schreef Harald van Dijk:
> case /dev in $pat) echo why ;; esac
>
> Now, bash and dash say that the pattern does match -- they take the
> backslash as unquoted, allowing it to escape the v. Most other shells
> (bosh, ksh93, mksh, pdksh, posh, yash, zsh) still take the
The xtrace (set -x) output in dash is a bit of a pain, because arguments
containing whitespace aren't quoted. This can it impossible to tell
which bit belongs to which argument:
$ dash -c 'set -x; printf "%s\n" one "two three" four'
+ printf %s\n one two three four
one
two three
four
Another
Op 27-03-18 om 20:23 schreef Larry Hynes:
> Funny, I did wonder if it might be a contraction, but I did find
> it odd that it's not mentioned or explained. I'll leave it be, if
> you all are happy enough to keep it 'as is', or can resubmit if you
> think it's warranted.
I think the simple fact
Op 26-03-18 om 12:30 schreef Harald van Dijk:
> With the snipping it's not clear that I was specifically confused by the
> inconsistency.
>
> I had included another example:
>
> pat="/de\v"
> printf "%s\n" $pat
>
> I can understand treating backslash as quoted, or treating it as
> unquoted,
Op 26-03-18 om 14:12 schreef Harald van Dijk:
> On 26/03/2018 13:57, Martijn Dekker wrote:
>> I don't see any inconsistency. Expansions are consistently treated
>> differently within 'case' than outside it. Among other things,
>> expansions within 'case' are *not* subject
evalvar() records empty expansion results (varlen == 0) as string
regions that need to be scanned for IFS characters. This is pointless,
because there is nothing to split.
This patch fixes the following bug, which is apparently a side effect of
the above:
$ dash -c 'IFS=; set --
set --
It's 2018 and UTF-8 is the de-facto standard character set for the
shell. IMO, supporting it should no longer be considered optional.
Busybox ash mostly tracks dash in applying patches and such, but it does
a good job of supporting UTF-8. The licenses are bidirectionally
compatible. Perhaps UTF-8
Op 22-03-18 om 10:35 schreef Herbert Xu:
> Martijn Dekker <mart...@inlv.org> wrote:
>>
>> evalvar() records empty expansion results (varlen == 0) as string
>> regions that need to be scanned for IFS characters. This is pointless,
>> because there is nothing to spli
Op 22-03-18 om 20:12 schreef Harald van Dijk:
> Isn't all of busybox, including ash, GPL? Wouldn't that mean that if any
> busybox code is imported into dash, that from then on dash can only be
> distributed under GPL?
I thought dash was already effectively under the GPL due to including
the
Op 22-03-18 om 20:28 schreef Harald van Dijk:
> On 22/03/2018 03:40, Martijn Dekker wrote:
>> evalvar() records empty expansion results (varlen == 0) as string
>> regions that need to be scanned for IFS characters. This is pointless,
>> because there is nothing to split.
&
Op 23-03-18 om 05:37 schreef Herbert Xu:
> 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
Op 22-03-18 om 23:16 schreef Harald van Dijk:
> 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.
Then maybe both that and not recording empty split regions should be done.
My C-fu may
Op 23-03-18 om 15:34 schreef Martijn Dekker:
> Op 23-03-18 om 11:58 schreef Herbert Xu:
>> Thanks, the problem here is that we need to set c to 0 not just
>> when quoted is true but also if sep is 0 since both imply that
>> field splitting is disabled. Here is an second rev
Op 04-03-18 om 11:44 schreef Harald van Dijk:
> When CTLENDVAR is seen, I double-check that syntax has the expected
> value. This fixes the handling of "${$+"}"}", where the inner } was
> seen as ending the variable substitution.
Also looks like dash with your patch considers the "}" to be
Op 04-03-18 om 16:46 schreef Harald van Dijk:
> FreeBSD sh also prints a blank line here.
[...]
> Like above, FreeBSD sh behaves like ksh.
I stand corrected.
Is there any port of FreeBSD sh to other operating systems? It would be
much more convenient for me to include it in my tests if I didn't
dash compiled on Mac OS X (macOS) and FreeBSD manifests the following bug:
$ dash -c 'x=; echo $((x))'
dash: 1: Illegal number:
This error is printed instead of the expected default "0" that should be
substituted for an empty variable in an arithmetic expression.
The bug does not occur on
Op 06-03-18 om 00:23 schreef Harald van Dijk:
> On 3/6/18 12:23 AM, Martijn Dekker wrote:
>> "All variables shall be initialized to zero if they are not otherwise
>> assigned by the input to the application."
>
> In your example, x has been assigned. Its value
Op 05-03-18 om 22:41 schreef Harald van Dijk:
> On 3/5/18 1:32 AM, Martijn Dekker wrote:
>> dash compiled on Mac OS X (macOS) and FreeBSD manifests the following
>> bug:
>>
>> $ dash -c 'x=; echo $((x))'
>> dash: 1: Illegal number:
>>
>> This error
I encountered another bug, introduced by 3cd5386 and not fixed by v2 of
this patch: the presence of a length-counting expansion like ${#foo} in
a string causes the rest of the string to be discarded.
$ src/dash -c 'foo=bar; echo "baz ${#foo} quux"'
baz 3
$ src/dash -c 'foo=bar; echo baz\
Commit 3cd538634f71538370f5af239f342aec48b7470b broke these:
$ src/dash -c 'unset var; echo ${var+set}'
set
$ src/dash -c 'var=; echo ${var:+nonempty}'
nonempty
HTH,
- M.
Op 01-01-19 om 17:24 schreef Harald van Dijk:
The immediate problem can be fixed either by dropping support for the
non-standard and undocumented fc -s [...]
Actually, it's standard:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html
| -s
| Re-execute the command without
On dash and on gwsh, the 'fc -s' command, that re-executes a command
from the history, executes the command repeatedly in an infinite loop.
It should execute it just once.
$ dash
$ echo foo
foo
$ fc -l
1 echo foo
$ fc -s 1
echo foo
foo
echo foo
foo
echo foo
foo
echo foo
foo
echo foo
foo
Op 01-01-19 om 20:02 schreef Harald van Dijk:
On 01/01/2019 18:59, Martijn Dekker wrote:
Op 01-01-19 om 17:24 schreef Harald van Dijk:
The immediate problem can be fixed either by dropping support for the
non-standard and undocumented fc -s [...]
Actually, it's standard:
I didn't say fc -s
Op 16-01-19 om 22:39 schreef Martijn Dekker:
> Op 16-01-19 om 14:32 schreef Herbert Xu:
>> Thanks for the patch. I took a deeper look into the history of
>> the bug and it turned out that I added REALLY_CLOSED as an
>> optimisation in order to avoid an unnecessary close(
Op 16-01-19 om 14:32 schreef Herbert Xu:
> Thanks for the patch. I took a deeper look into the history of
> the bug and it turned out that I added REALLY_CLOSED as an
> optimisation in order to avoid an unnecessary close(2) syscall.
Does this actually save cycles? I'm probably missing something,
Op 16-01-19 om 14:32 schreef Herbert Xu:
> So I'm going to go for a more complicated fix:
The v3 patch introduces a bug:
begin test script
init() {
exec 8&-
{
init
: <&8 && echo ok
} 8<&-
end test script
Actual output:
test2.sh: 9: test2.sh: 8: Bad file
[Corrected patch due to an oops in first take. Apologies.]
Op 19-09-18 om 05:25 schreef Herbert Xu:
Harald van Dijk wrote:
On 23/04/2018 19:56, Martijn Dekker wrote:
$ dash -c '{ exec 8
What surprises me most is that dash has code written specifically to
keep the fd closed. dash would
Op 19-09-18 om 05:25 schreef Herbert Xu:
Harald van Dijk wrote:
On 23/04/2018 19:56, Martijn Dekker wrote:
$ dash -c '{ exec 8
What surprises me most is that dash has code written specifically to
keep the fd closed. dash would be smaller and simpler if it behaved the
way you expected
Op 29-11-18 om 20:56 schreef Harald van Dijk:
That's part of it, but not the whole story. Herbert Xu's comment about
exitshell() was right, that is still a problem. A testcase for this is
trap '(true) || echo bug' EXIT
Yes. Thanks. I hadn't thought about that.
The test case above is not
Op 29-11-18 om 21:39 schreef Harald van Dijk:
By the way, my change has an unintended but possibly acceptable side
effect:
trap '(trap "echo exit" EXIT; :)' EXIT
This prints nothing with current dash, but prints "exit" with my change.
It also prints "exit" in ksh, mksh, posh, and bosh.
Op 29-11-18 om 12:33 schreef Herbert Xu:
Thanks for the report. This patch should fix the problem:
Doesn't work for me, in fact it seems to make no difference.
Here are a few more test cases.
(trap '(! :) && echo BUG1' EXIT)
(trap '(false) && echo BUG2' EXIT)
(trap 'readonly foo=bar;
Op 29-11-18 om 15:48 schreef Herbert Xu:
The problem is that in evalsubshell we end up in exitshell again
which restores the old exit status. So we need to come up with
a way to differentiate the exitshell from the original shell vs.
a subshell.
Isn't it much simpler than that? Upon forking a
Op 27-11-18 om 17:24 schreef Martijn Dekker:
Big bad bug: it appears that subshells always return status 0 in traps.
Bug found in dash 0.5.9 and later.
In fact, the bug exists on at least dash 0.5.6 and possibly earlier
(earlier versions don't compile for me) if the exit occurs due
Op 27-11-18 om 17:24 schreef Martijn Dekker:
Big bad bug: it appears that subshells always return status 0 in traps.
As posted elsewhere, looks like the problem is simply that savestatus
("/* exit status of last command outside traps */") isn't reset to -1
upon resetting traps wh
Another bug introduced by 3cd5386, and not fixed in current git.
String length expansion ${#v} aborts string processing.
$ ./dash -c 'v=abc; echo ab${#v}cd'
ab3
Expected output: ab3cd
Yes, you really need that regression test suite. I can help you start
one off. Would you be willing to
Big bad bug: it appears that subshells always return status 0 in traps.
Bug found in dash 0.5.9 and later.
$ src/dash -c 'trap "(false) && echo BUG" INT; kill -s INT $$'
BUG
$ src/dash -c 'trap "(false) && echo BUG" EXIT'
BUG
$ src/dash -c 'trap "(false); echo \$?" EXIT'
0
Workaround: if an
Op 10-01-19 om 11:37 schreef Martijn Dekker:
> In a dot script sourced with 'command .' (which is useful to avoid
> exiting if the script doesn't exist), triggering a syntax error in an
> 'eval' in a subshell causes dash to hang at the end of the main script.
In fact, 'eval' doesn
For unset foo:
dash-git
$ src/dash -c 'set -- ${foo- bar }; echo "[$1]"'
[bar ]
Release versions of dash and all other shells output:
[bar]
The change in behaviour appears to have been introduced by commit
3cd5386 ("expand: Do not reprocess data when expanding words").
- Martijn
--
modernish
Op 18-07-19 om 22:15 schreef Martijn Dekker:
Regarding precedent: as far as I know, among POSIXy shells, a recursion
limit is currently only implemented in zsh, with a user-settable
FUNCNEST variable.
I was mistaken: both AT ksh93 and NetBSD 8.1 sh have a hard-coded
limit of 1000.
- M
Op 18-07-19 om 20:27 schreef Jason Bowen:
A recursion limit is not without precedent. CPython sets a platform-
dependent recursion limit for this same purpose:
https://docs.python.org/3/library/sys.html#sys.setrecursionlimit
But indeed, the limit is "artificial" or arbitrary. It should just be
Op 22-07-20 om 04:58 schreef Herbert Xu:
Thanks for the report, does this patch help?
Yup, all fixed. Thanks.
- M.
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
This commit introduced the build failure:
3e3e7af1a49273a5e49d50565b3b079a2ab19142
The first error is:
expand.c:1365:9: error: incomplete definition of type 'struct dirent64'
if (dp->d_name[0] == '.' && ! matchdot)
~~^
Full build log:
$ uname -a
Darwin
68 matches
Mail list logo
