I agree that this is a useful feature (including that export a=$b does
not split words and export a=* does not generate pathnames); FreeBSD sh
has had it for a few years:
https://cgit.freebsd.org/src/commit/?id=84fbdd8ca068ec63c6c9a931303d3811738128cb
.
It is specified by
This was fixed between dash 0.5.5 and 0.5.6 by
commit 9655c1ac5646bde1007ecba7c6271d3aa98f294b
Date: Tue Mar 9 12:52:30 2010 +0800
[ARITH] Fix binary operator parsing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Catching SIGCHLD in dash does not help in this case, since dash is
already gone (execve'ed) by the time the SIGCHLD would come.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/915158
Title:
Process
You can see the same problem with any shell with a command like
(sleep 3 exec /bin/sleep 6)
because most versions of /bin/sleep do not clean up zombies (here, a
zombie from an inherited child process).
Dash does not consider the existence of a background process a reason to
fork for an
*** This bug is a duplicate of bug 259671 ***
https://bugs.launchpad.net/bugs/259671
The backslash escape sequences are being processed by echo, not
read. You can avoid this inconsistency by doing something like
printf %s\n '000\n999' | dash -c ' read -r f ; printf %s\n $f '
** This bug has
** Also affects: unity
Importance: Undecided
Status: New
** Changed in: dash (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/782701
Title:
Cant paste
** Also affects: unity
Importance: Undecided
Status: New
** Changed in: dash (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/774447
Title:
Dash text
This applies to the Unity desktop shell, not the /bin/dash shell.
** Also affects: unity
Importance: Undecided
Status: New
** Changed in: dash (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This bug is not relevant to the /bin/dash shell (normally /bin/sh is a
link to this).
** Also affects: unity
Importance: Undecided
Status: New
** Changed in: dash (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs,
You need to quote the operators to distinguish them from redirections.
It may be appropriate to mention this in the man page.
For example:
$ [ 2.6 2.7 ]; echo $?
0
$ [ 2.6 2.7 ]; echo $?
1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Upstream seems to have said no fix is planned: http://www.mail-
archive.com/d...@vger.kernel.org/msg00200.html
Furthermore, I have tried this command in various other shells and it
does not work in zsh, ksh93 and mksh either. (ksh93 has a different,
incompatible way to use fds greater than 9.)
Be sure to verify that the script works with bash's non-POSIX mode as
well. A not so well known feature of bash is that it enters POSIX mode
when called as sh. This causes various subtle differences. Therefore,
a #!/bin/sh script with /bin/sh - bash might behave differently from a
#!/bin/bash
Be sure to verify that the script works with bash's non-POSIX mode as
well. A not so well known feature of bash is that it enters POSIX mode
when called as sh. This causes various subtle differences. Therefore,
a #!/bin/sh script with /bin/sh - bash might behave differently from a
#!/bin/bash
*** This bug is a duplicate of bug 422298 ***
https://bugs.launchpad.net/bugs/422298
** This bug has been marked a duplicate of bug 422298
dash interpreter don't handle some unicode characters correctly
* You can subscribe to bug 422298 by following this link:
*** This bug is a duplicate of bug 259671 ***
https://bugs.launchpad.net/bugs/259671
** This bug has been marked a duplicate of bug 259671
dash: echo builtin interprets backslash escape sequences
* You can subscribe to bug 259671 by following this link:
*** This bug is a duplicate of bug 259671 ***
https://bugs.launchpad.net/bugs/259671
** This bug has been marked a duplicate of bug 259671
dash: echo builtin interprets backslash escape sequences
* You can subscribe to bug 259671 by following this link:
The Debian dash maintainer considers this a WONTFIX:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550399
It seems unlikely that Ubuntu will want to override this.
** Summary changed:
- dash parses backslashes in single quotes
+ dash: echo builtin interprets backslash escape sequences
**
** Bug watch added: Debian Bug tracker #595063
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063
** Also affects: dash (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063
Importance: Unknown
Status: Unknown
--
read builtin can't handle some synthetic files
This was fixed in upstream in git commit
09363426739388813a53d63716d15163f6c43caf, March 2010.
--
dash: Redirection operator should not truncate file
https://bugs.launchpad.net/bugs/598054
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
You may want this, but allowing only fd 0-9 is not a POSIX violation.
XCU 2.7 Redirection says the maximum fd for redirection is
implementation-defined and must be at least 9. This is sufficient for
most applications.
--
dash does not support multi-digit file descriptors
I consider this a kernel bug, it should be possible to read regular
files one byte at a time (like dash's and zsh's read builtins do).
--
read builtin can't handle some synthetic files
https://bugs.launchpad.net/bugs/598279
You received this bug notification because you are a member of Ubuntu
This patch has been pushed to dash.git. However, applying it to an older
version of dash could be useful so people can take advantage of this fix
without the possible instability and possible subtle incompatibilities
of a new dash version.
--
dash interpreter don't handle some unicode characters
POSIX says PPID should be set once at shell initialization, and I have
not seen a shell which does otherwise.
--
Bash PPID is wrong when parent terminates
https://bugs.launchpad.net/bugs/340571
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
You can avoid these problems by using the printf utility instead of
echo.
--
Wrong escape character processing in dash
https://bugs.launchpad.net/bugs/268929
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I think you should just cope with this (by not shifting more than $#),
as there are other shells with the same behaviour.
--
shift function does not work as expected.
https://bugs.launchpad.net/bugs/548902
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I think the real problem is in gdm here: if it wants to read the user's
shell startup files, it should do so using the user's login shell, not
/bin/sh. User shell startup files cannot be guaranteed to even parse in
/bin/sh, and changing /bin/sh to make it work degrades sh -n for actual
/bin/sh
This bug should be tightened down to the completion only.
The discrepancy between cd and pwd on one hand and other utilities on
the other hand is inevitable (unless you disable the symlink magic using
set -P).
I consider the fact that /bin/pwd shows the path without symlinks a bug
in GNU
This is because bash's time is a keyword, not a builtin command ('type
time' will show). Therefore it will only be recognized if it is in the
input literally and unquoted.
--
`time` crashes in a script
https://bugs.launchpad.net/bugs/356624
You received this bug notification because you are a
Dash deliberately does not support arrays, so this is not a bug in dash.
I suggest changing the #!/bin/sh line at the start of the script to
#!/bin/bash. (Note that bash enters posix mode when it is called as
'sh', so it may be a good idea to add (set -o posix) 2/dev/null set
-o posix to the
The issue is not with the single quotes, but with dash's echo builtin.
Apparently, the way they are compiled and configured by default on
Ubuntu, dash's echo builtin interprets backslash escape sequences while
bash's does not.
According to POSIX, this interpretation is permitted; with the XSI
I don't consider this a bug.
Given you say Bourne shell, see this session with an original Bourne
shell (Heirloom toolchest jsh, close to Solaris 10 /bin/sh):
$ type ls
ls is /bin/ls
$ type ls
ls is /bin/ls
$ ls /
COPYRIGHT dev homeproctmp
bin
local will not be removed from dash, as it is used too much, even
though it is not in POSIX.
The underlying problem is related to a feature in bash which also
applies to some POSIX special builtins (export and readonly). This
feature is not in POSIX and strictly speaking conflicts with it.
Dash
This has been discussed at the Austin Group (POSIX fixing/development)
recently, but no definitive interpretation has been issued yet. The
current standard is rather vague to allow various implementations to
comply.
I agree that bash's behaviour is better here, but it is possible that
the
33 matches
Mail list logo
