Re: [BUG] 'nolog' and 'debug' options cause "$-" to wreak havoc
2017-03-29 21:02:19 +0200, Martijn Dekker: [...] > [*] "nolog: Prevent the entry of function definitions into the command > history; see Command History List." > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03 [...] For the record, nolog is approved for deprecation: http://austingroupbugs.net/view.php?id=981 -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: Tests [ 0 -eq $UID ] don't work as in bash
2016-09-07 11:55:00 -0400, Paul Smith: > On Wed, 2016-09-07 at 16:44 +0200, Andrey Voropaev wrote: > > if [ 0 -eq $UID ] > > The variable UID is not defined to be automatically set by the shell in > POSIX; having it set is a bash extension. dash doesn't set it > automatically for you. > > You'll have to set it yourself: > > UID=$(id -u) > > Also you should quote variable references, in general: > > if [ 0 -eq "$UID" ] > > Be sure that if your scripts rely on bash-isms you start them with > #!/bin/bash and if you don't want them to rely on bash-isms, you start > them with #!/bin/sh. [...] Note that both zsh and bash have it, both from the start, both copied from tcsh ($uid in tcsh). In zsh, you can also set UID (and USERNAME and EUID, and GID...) to change your uid (assuming you have the permission to do so). $ sudo zsh -c 'id; UID=1000; id; UID=0' uid=0(root) gid=0(root) groups=0(root) uid=1000(chazelas) gid=0(root) groups=0(root) zsh:1: failed to change user ID: operation not permitted In bash, UID is read-only. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: dash drops exported bash functions
2016-02-11 15:30:59 +0100, Makarius: [...] > The problem is a deeper one, though: export -f in bash no longer > works for systems that have /bin/sh -> dash (i.e. Debian and > Ubuntu). [...] Note that pdksh/posh/mksh also strip those variables which it can't map to shell variable names (and have for decades). -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: dash: read does not ignore trailing spaces
2015-12-03 23:17:58 +, Stephane Chazelas: > 2015-12-03 23:04:31 +0000, Stephane Chazelas: > [...] > > > Summarising: POSIX states that "each occurrence in the input of an IFS > > > character that is not IFS white space, along with any adjacent IFS white > > > space, shall delimit a field". This *may* be interpreted to read that a > > > final non-whitespace IFS character denotes an empty final field, because > > > otherwise that final character wouldn't be delimiting any field, but > > > only terminating one. It's pretty ambiguous, though. > > [...] > > > > I agree the spec is not very clear > > http://thread.gmane.org/gmane.comp.shells.bash.bugs/4825 > > http://thread.gmane.org/gmane.comp.shells.bash.bugs/15768 > > > > But see this interpretation: > > https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html > > > > I can't find the austin-group discussions, but I'm pretty sure > > I've seen several and Chet is refering to one from 2005 over > > there. > [...] > > See also: > https://groups.google.com/forum/#!topic/comp.unix.shell/krZy2rvnv2g > (Geoff is from the OpenGroup). > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512438 > I actually was the one raising it for posh. I (and the posh > maintainer apparently) failed to notice that it was applying to > "read" there as well. [...] More: http://thread.gmane.org/gmane.comp.shells.bash.bugs/9661/focus=9662 Where Chet (I think) refers to: https://standards.ieee.org/findstds/interps/1003-2-92_int/pasc-1003.2-98.html The 2005 Austin group discussion can be seen on the web archive: http://web.archive.org/web/20050301075813/http://www.opengroup.org/austin/mailarchives/ One article there was forwarded to the zsh mailing list: http://www.zsh.org/mla/workers/2005/msg00306.html (but not acted upon) Which leads to https://www.opengroup.org/austin/aardvark/latest/xcubug2.txt confirming that https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html is contemporary and a follow-up of that 2005 discussion. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: dash: read does not ignore trailing spaces
2015-12-03 23:04:31 +, Stephane Chazelas: [...] > > Summarising: POSIX states that "each occurrence in the input of an IFS > > character that is not IFS white space, along with any adjacent IFS white > > space, shall delimit a field". This *may* be interpreted to read that a > > final non-whitespace IFS character denotes an empty final field, because > > otherwise that final character wouldn't be delimiting any field, but > > only terminating one. It's pretty ambiguous, though. > [...] > > I agree the spec is not very clear > http://thread.gmane.org/gmane.comp.shells.bash.bugs/4825 > http://thread.gmane.org/gmane.comp.shells.bash.bugs/15768 > > But see this interpretation: > https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html > > I can't find the austin-group discussions, but I'm pretty sure > I've seen several and Chet is refering to one from 2005 over > there. [...] See also: https://groups.google.com/forum/#!topic/comp.unix.shell/krZy2rvnv2g (Geoff is from the OpenGroup). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512438 I actually was the one raising it for posh. I (and the posh maintainer apparently) failed to notice that it was applying to "read" there as well. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: dash: read does not ignore trailing spaces
2015-12-03 22:43:39 +0100, Martijn Dekker: > Stephane Chazelas schreef op 03-12-15 om 22:17: > > It's meant to split into "a" and "b", not "a", "b" and "". As > > ":" is meant to be treated as a *delimiter* or *terminator*. > > That was my interpretation of the standard, too. So I reported this as a > bug to author of yash, but he reads the standard differently and came up > with a good argument for that. See: > > https://osdn.jp/ticket/browse.php?group_id=3863&tid=35283#comment:3863:35283:1435293070 > > Summarising: POSIX states that "each occurrence in the input of an IFS > character that is not IFS white space, along with any adjacent IFS white > space, shall delimit a field". This *may* be interpreted to read that a > final non-whitespace IFS character denotes an empty final field, because > otherwise that final character wouldn't be delimiting any field, but > only terminating one. It's pretty ambiguous, though. [...] I agree the spec is not very clear http://thread.gmane.org/gmane.comp.shells.bash.bugs/4825 http://thread.gmane.org/gmane.comp.shells.bash.bugs/15768 But see this interpretation: https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html I can't find the austin-group discussions, but I'm pretty sure I've seen several and Chet is refering to one from 2005 over there. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: dash: read does not ignore trailing spaces
2015-12-03 22:02:14 +0100, Harald van Dijk:
[]
> $ for shell in bash mksh posh zsh; do printf %s: "$shell"; $shell
> -c 'IFS=,; echo a, | { read v; echo "<$v>"; }'; done
> bash:
> mksh:
> posh:
> zsh:
>
> As far as I can tell, the posh/zsh behaviour is the correct
> behaviour, but I'm not convinced yet my interpretation is correct.
[...]
No, that would be the same as for:
v=a:b:
IFS=:
set -f
set -- $v
It's meant to split into "a" and "b", not "a", "b" and "". As
":" is meant to be treated as a *delimiter* or *terminator*.
That has been discussed a few times on the austin group mailing
list.
zsh and pdksh (and other descendants of the Forsyth shell) treat it as
separator (and are not compliant), mksh (derived from pdksh)
changed it recently. posh (also based on pdksh) still hasn't changed it.
That's a bit counter-intuitive and means for instance you can't
use $IFS to split variables like $PATH/$LD_LIBRARY_PATH...
In the case of read, it even makes less sense because:
~$ echo a:: | sh -c 'IFS=: read a; echo "$a"'
a::
~$ echo a: | sh -c 'IFS=: read a; echo "$a"'
a
But that's how it's specified.
So dash is indeed conformant there.
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
Re: [BUG] dash uses $* instead of $@ in variable assignments
2015-11-26 20:44:26 +0100, Gioele Barabucci: > Hello, > > I am forwarding a bug [1] reported by a Debian user: dash incorrectly > uses `$*` instead of the requested `$@` inside variable assignments. > The current version of dash is affected by this bug. > > A simple test from the original reporter: > > $ dash -c 'IFS=:$IFS ; set -- a b c ; echo "$@" ; x="$@" ; echo "$x"' > a b c > a:b:c [...] This behaviour is what I expect and is common to other shells as well. $* and $@ are the concatenation of the positional parameters with the first character of $IFS, but "$@" in list contexts expands to all the position parameters as separate words. That's a logical continuation to the Bourne behaviour (which concatenated on space instead of the first character of $IFS). POSIX used to be unclear about it. I had raised the issue some time ago and I beleive there's a new wording. See the longish discussion at http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9972 In any case, you should only use $@ quoted and in list contexts. $* may be used quoted in non-list contexts. IIRC the proposed new wording for the POSIX spec would make this behaviour of dash non-conformant: $ dash -c 'set a b c; IFS=; echo $*' abc (even though I'd argue it's a logical design choice). -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: [bug?] echo -n does not work as described
2015-11-11 22:46:02 -0500, Kevin Korb: [...] > >>> NOTE: your shell may have its own version of echo, which > >>> usually super‐ sedes the version described here. Please refer > >>> to your shell's docu‐ mentation for details about the options > >>> it supports. > > > >> By the way, 'echo -n' is non-portable, and POSIX says you should > >> use 'printf' instead. > > If dash refuses to supply a compatible version of echo then dash must > not include a builtin version of echo. If dash didn't have a broken > embedded version of echo I wouldn't have a problem. [...] To clarify, a few things, sh and the POSIX/Unix utilities like C nowadays is a language that has a (well several) standard that defines it, and several existing implementations of interpreters that interpret that language. Among the most recognised specifications, we have POSIX and Unix. Both specifications have now been merged. To simplify, the Unix spec is like the POSIX spec but where a few optional parts are required. So basically we have the POSIX syntax for sh and utilities and the Unix syntax. In the POSIX syntax, the behaviour for: echo -n whatever is unspecified. That means that a POSIX conformant script, or a script written to be portable to POSIX conformant systems must not call echo with a first argument that may be -n. We're told to use printf instead there: printf %s "$var" instead of echo -n "$var" Same goes for any argument that contains backslash character. In the Unix syntax however, the behaviour of echo is clearly specified. echo -n whatever is required to output "-n whatever", so your dash is both POSIX and Unix conformant in that regard. The builtin echo of bash, by default is neither POSIX nor Unix conformant unless both the xpg_echo and posix (that one enabled when called as sh) options have been enabled. More details at: http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo In short, don't use echo. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: [BUG] ${#var} returns length in bytes, not characters
2015-06-03 13:29:33 +0200, Martijn Dekker:
> 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 is invalid for locales that include multi-byte
> characters, such as the now ubiquitous UTF-8 set.
[...]
See also:
http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9972/focus=10040
For a few UTF-8 related variations in behaviour between shells
(including this one), though many of them are about "unspecified
behaviour".
The script mentioned there is also attached here.
--
Stephane
euro=$(printf '\342\202\254')
o342=$(printf '\342')
o202=$(printf '\202')
o254=$(printf '\254')
test_shell=$1
n=0
case $test_shell in
zsh) emulate sh;;
zsh5) setopt shwordsplit;;
[lm]ksh) set -o utf8-mode;;
esac
if [ -n "$test_shell" ]; then
printf '%8s:' "$test_shell"
testing() {
n=$(($n + 1))
test
ret=$?
[ "$ret" -eq "$na" ] && ret=-
printf ' %2s' "$ret"
[ "$ret" = "$1" ] && printf '\342\203\235'
}
else
testing() {
n=$(($n + 1))
printf '%2d: %s (expected: %d)\n' "$n" "$2" "$1"
}
fi
na=99
if_accept_invalid() { [ "$o254" ] || exit "$na"; }
if_printf_builtin() {
case $(type printf 2> /dev/null) in
*builtin*);;
(*) exit "$na"
esac
}
test() (
exit "${#euro}"
)
testing 1 '${#utf8-character}'
test() (
if_accept_invalid
exit "${#o254}"
)
testing 1 '${#single byte, invalid char}'
test() (
if_accept_invalid
t=$o342$o202
exit "${#t}"
)
testing 2 '${truncated character, 2 bytes}'
test() (
if_accept_invalid
case $euro in
*"$o254"*) true;;
*) false
esac
)
testing 0 '$char contains byte component'
test() (
if_accept_invalid
t=+$euro-
[ "${t##*"$o254"}" = - ]
)
testing 0 '${##} matching with byte components of $mbchar'
test() (
if_accept_invalid
t=+$o254$euro-
[ "${t##*"$euro"}" = - ]
)
testing 0 '${##} works in invalid strings'
test() (
if_accept_invalid
IFS=$o254
t=+$euro+
set -- $t
exit "$#"
)
testing 2 'byte component found in $mbchar by IFS'
test() (
if_accept_invalid
IFS=$o342$o202
t=+$euro+
set -- $t
exit "$#"
)
testing 3 'byte component found in $mbchar by IFS'
test() (
if_accept_invalid
IFS=$o254
t=+$o254+
set -- $t
exit "$#"
)
testing 2 'IFS works with bytes'
test() (
IFS=$euro
t=+$euro+
set -- $t
exit "$#"
)
testing 2 'IFS works with mbchars'
test() (
if_accept_invalid
IFS=$euro
t=+$o254$o342$euro+
set -- $t
exit "$#"
)
testing 2 'IFS works with mbchars in invalid strings'
test() (
if_accept_invalid
IFS=$o342$o202
set / /
[ "$*" = "/$o342/" ]
)
testing 0 'Joining $* with byte forming invalid char'
test() (
IFS=$euro
set / /
[ "$*" = "/$euro/" ]
)
testing 0 'Joining $* with mbchar'
test() (
if_printf_builtin
exit "$(printf '%4s' "$euro" | wc -c | tr -cd 0-9)"
)
testing 6 'byte length of 4-padded euro'
test() (
if_accept_invalid
if_printf_builtin
exit "$(printf '%4s' "$o342$o202" | wc -c | tr -cd 0-9)"
)
testing 4 'byte length of 4-padded truncated mbchar'
test() (
case $euro in
?) true;;
(*) false
esac
)
testing 0 '? matches mbchar'
test() (
if_accept_invalid
case $o342$o202 in
??) true;;
(*) false
esac
)
testing 0 '?? matches 2-byte truncated mbchar'
echo
if [ -z "$test_shell" ]; then
printf '%8s:' tests
i=1; while [ "$i" -le "$n" ]; do
printf ' %2d' "$i"
i=$(($i + 1))
done
printf '\n\n'
for test_shell in dash zsh yash bash lksh mksh ksh93 zsh5 posh; do
"$test_shell" "$0" "$test_shell"
done
fi
Re: Bug#501566: [MAN] Clarify two redirection mechanisms
2014-12-08 22:22:03 +0100, Stéphane Aulery: > Le lundi 08 décembre 2014 à 08:37:38, Stephane CHAZELAS a écrit : > > 2014-12-08 19:50:05 +0100, Stéphane Aulery: > > >>>> [n1]>&n2Redirect standard output (or fd n1) to the same "open > > >>>> file description" as on fd n2. > > >>>> > > >>>> [n1]>&n2Copy fd n2 as stdout (or fd n1) [...] > I wonder more and more if Herbert is willing to accept this tiny patch > or another. I would not be wasting his time if he does not want or can > not take care of that. This is free software, there is no obligation. [...] What matters here is the mistake fixed in the manual. n>&p has been around since the end of the 70s. It's unlikely anyone will learn anything about it from the dash man page. Let's make it: [n1]>&n2Copy file descriptor n2 as stdout (or fd n1) [n1]<&n2Copy file descriptor n2 as stdin (or fd n1) That's more or less the POSIX wording. It may not be as descriptive as other ones, but I can't imagine anyone complaining about the correctness or accuracy of it. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: Bug#501566: [MAN] Clarify two redirection mechanisms
2014-12-08 19:50:05 +0100, Stéphane Aulery:
[n1]>&n2Redirect standard output (or fd n1) to the same "open
file description" as on fd n2.
[n1]>&n2Copy fd n2 as stdout (or fd n1)
[n1]>&n2Redirect standard output (or fd n1) to the same
resource as currently open on fd n2.
> >> "Resource" is rather unwieldy, how about simply "file"?
> >
> > "file" could be misleading
> >
> > [...]
> >
> > IMO, "resource" is vague enough so as not to give the wrong idea
> > and I like that wording because it conveys the intended
> > mechanism clearly ("redirect to same thing as"). But I agree
> > it's not ideal.
>
> It is true that "resource" is dissonant as "file" is too restrictive. The
> term "file descriptor" is used above. Why not use it again?
[...]
If you say redirect fd n1 to fd n2, you confuse people (and I've
seen a lot of people being confused in such a way) as they
start thinking the fds become somehow linked (for instance that
in 2>&1 > file, stderr goes to stdout and then both to "file"
which is not the case). When you start thinking of "&" as
"/address/ of" (yet another improper wording) or "resource
currently open on", that clears that confusion.
If you don't like the "resource" wording, you can always got for
the "copy" one above or the POSIX wording:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
I've seen "resource" used in the past, I've used it myself a few
times in usenet articles:
https://groups.google.com/d/msg/comp.unix.shell/48beJpLdjNE/jUak98HUekUJ
https://groups.google.com/d/msg/comp.unix.questions/EQL477tzYKk/J9ysMfqc5YIJ
https://groups.google.com/d/msg/comp.unix.aix/WcWsocnEHS0/hgSDWt19SaYJ
(see the aforementioned confusion in some of the messages that
those were replying to).
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
Re: [MAN] Clarify two redirection mechanisms
2014-12-01 18:04:56 +0800, Herbert Xu:
[...]
> > --- a/src/dash.1
> > +++ b/src/dash.1
> > @@ -402,11 +402,13 @@ Append standard output (or n) to file.
> > .It [n] Ns \*[Lt] file
> > Redirect standard input (or n) from file.
> > .It [n1] Ns \*[Lt]& Ns n2
> > -Duplicate standard input (or n1) from file descriptor n2.
> > +Redirect standard input (or fd n1) from the same resource as currently
> > open on
> > +fd n2.
>
> "Resource" is rather unwieldy, how about simply "file"?
[...]
"file" could be misleading (as actually it's dup(2)ing a file
descriptor, so more like redirecting to same _open file
description_ (not the same as reopening the file like "n1>
/dev/fd/n2" does on Linux for instance) and "file" is understood
by many as "regular file" while here, it could be (and often is)
socket/pipe/devices...).
IMO, "resource" is vague enough so as not to give the wrong idea
and I like that wording because it conveys the intended
mechanism clearly ("redirect to same thing as"). But I agree
it's not ideal.
The "dupliciting fd x onto y" wording may be more correct, but
doesn't convey the redirection idea as clearly IMO.
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
command substitutions in $PS4
Hello. [tested on current git head f6d4def4e27b13fab174e948b94cd10550d3e10e] Command substitution doesn't seem to work in $PS4 (used for xtrace prompt): $ PS4='$(date +%T)> ' dash -xc : dash: 1: Syntax error: end of file unexpected (expecting ")") And with the old syntax: $ PS4='`date +%T`> ' dash -xc : > : And with more than one command: $ PS4='`date +%T`> ' dash -xc ':;:' > : dash doesn't return and seems to go in a forking loop, presumably because the `date` there triggers another PS4 expansion and so on recursively If I prevent the recursion with: --- a/src/eval.c +++ b/src/eval.c @@ -776,7 +776,15 @@ evalcommand(union node *cmd, int flags) int sep; out = &preverrout; + + /* +* reset xflag temporarily for command substitutions performed +* upon $PS4 expansion +*/ + xflag = 0; outstr(expandstr(ps4val()), out); + xflag = 1; + sep = 0; sep = eprintlist(out, varlist.list, sep); eprintlist(out, arglist.list, sep); $ PS4='`date +%T`> ' ./src/dash -xc ':;sleep 1; date' > : 21:43:47> sleep 1 21:43:48> date Mon Nov 17 21:43:48 GMT 2014 The command substitution still fails upon the first expansion only. I quickly gave up trying to find out why as I found the code there hard to follow. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: Bug#501566: dash: details of redirection/duplication in manpage are reversed
2014-11-11 14:23:21 +0100, Stephen Shirley: [...] > "[n1]>&n2Redirect standard output (or n1) to n2." > > It doesn't cover the case where n2 is later changed, and how n1 does > not follow this, but it's the simplest fix i see. [...] That's ambiguous. Maybe: [n1]>&n2Redirect standard output (or fd n1) to the same "open file description" as on fd n2. [n1]>&n2Redirect standard output (or fd n1) to the same resource as open on fd n2. [n1]>&n2Copy fd n2 as stdout (or fd n1) ? -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: % in $PATH
2014-11-10 23:39:51 +0100, Guido Berhoerster: [...] > That leaves the /path%func > case but there is precendence with FPATH as a solution if "%" is > to be completely eliminated from PATH. [...] Where ash's $PATH handling is superior to $FPATH is that you can specify which fpath component has precedence over which path component and over builtins. My problem as reported is that the namespace reserved by ash (any component with % in it) was too wide (and unnecessarily so). If you make it any component ending in %func or %builtin, that's far less of an issue (as long as it's documented). I won't shed a tear if that feature is removed. I'm just feeling it's not necessary to remove it, it could just be made more innocuous. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: % in $PATH
2014-11-10 22:59:38 +0100, Guido Berhoerster: [...] > A much nicer solution would be to do something similar to the > original Korn shell and assign additional builtins a virtual > path which can be freely assigned in PATH and with which they can > be explicitly called. No more "%" in PATH and the feature can > be retained. [...] Sounds to me like it's what dash does. It has %builtin (or /%builtin) where ksh93 has /opt/ast/bin. With ksh93, that's only for a few extra builtins that are only enabled if you add /opt/ast/bin to $PATH (or you can call them with "command /opt/ast/bin/cat"). I wouldn't say it's much better, it's still bad as being the hijacking of one namespace for something else. dash's %builtin (as opposed to /path/to/functions%func) is potentially dangerous though because if you have that in your $PATH, you're vulnerable to attackers planting %builtin directories (in /tmp for instance) which will be considered by other things than dash/ash when looking up $PATH. That's worked around by using /%builtin instead of %builtin though. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: % in $PATH
2014-11-10 21:20:02 +0800, Herbert Xu:
> On Wed, Nov 05, 2014 at 11:59:47AM +0000, Stephane Chazelas wrote:
> > Hello,
> >
> > ash/dash have a nice feature that allows to have:
> >
> > PATH=/bin:%builtin:/usr/bin:/some/dir%func:/sbin
> >
> > To have commands in /bin take precedence over builtins and
> > files in /some/dir being looked up for autoloaded functions (a
> > bit like FPATH in ksh/zsh).
> >
> > That's nice but the way it is implemented, that means that %
> > characters in $PATH cause problems. See for instance:
> >
> > http://unix.stackexchange.com/questions/126955/percent-in-path-environment-variable
>
> I'm inclined to just kill this feature, or at least make it a
> configuration option that's disabled by default.
[...]
Though I'd agree there's little chance of many people using it as
the documentation about it has been removed in dash, I don't
think there's any harm in leaving it in but implemented the way
I suggest.
It's useful as an equivalent to bash's exported functions (and
is a better/safer approach IMO) as an instrumentation tool.
Example: redefine "echo" as a Unix conformant one before running
something that expects a Unix conformant "echo":
$ printf '%s\n' 'echo() { local IFS=" "; printf "%b\n" "$*"; }' > echo
$ PATH=$PWD%func:%builtins:$PATH dash -c 'echo "-n\c"; echo x'
-nx
I don't see the point in keeping it if it's to make it disabled
by default though (unless we add an equivalent of BASHOPTS which
can be used to turn it on via the environment)
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
% in $PATH
Hello, ash/dash have a nice feature that allows to have: PATH=/bin:%builtin:/usr/bin:/some/dir%func:/sbin To have commands in /bin take precedence over builtins and files in /some/dir being looked up for autoloaded functions (a bit like FPATH in ksh/zsh). That's nice but the way it is implemented, that means that % characters in $PATH cause problems. See for instance: http://unix.stackexchange.com/questions/126955/percent-in-path-environment-variable Where someone ran into it when they had a: /home/torbjorr/deployed/vector/x86_64-GNU%2fLinux directory in there. Given than only "builtin" and "func" are recognised after "%", I think it would be better if the PATH handling accepted any other string like "foo%bar", "foo%2f", "foo%functions" as-is as a normal $PATH component. And foo%2fbar%func meaning "foo%2fbar" treated as a directory with autoloadable functions. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: [EXPAND] Split unquoted $@/$* correctly when IFS is set but empty
2014-10-08 15:26:36 +0800, Herbert Xu: > commit 3c06acdac0b1ba0e0acdda513a57ee6e31385dce > Author: Herbert Xu > Date: Wed Oct 8 15:24:23 2014 +0800 > > [EXPAND] Split unquoted $@/$* correctly when IFS is set but empty > > 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. [...] Well, if IFS is empty, field splitting is disabled. There's nothing in POSIX that clearly says that $@ and $* should expand to the positional parameters *as separate arguments in list contexts*. yash and the Bourne shell behave like dash. Only shells with array support behave differently. The whole $*/$@ expansion is rather unclear in the POSIX spec. I've just raised the problem on the Austin group mailing list. See also http://thread.gmane.org/gmane.linux.debian.devel.general/197901 Cheers, Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: Dashhh
2011-11-17, 13:38(-07), Eric Blake:
[...]
>> sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/& loca=
> l FUNCNAME=3D\1;/'
>
> Except that 'local' is not part of POSIX, so while this conversion may
> work for dash, it's not a portable catch-all for other compliant shells.
[...]
Though "local" is in LSB, so supported by sh implementations on
Linux. Which is probably why even posh supports it. However LSB
only supports:
local var
var=value
Not
local var=value
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
Re: Dashhh
2011-11-17, 17:17(+01), Heiko Gerstung:
[...]
> 1. The usual "[[" and "==" stuff (pretty easy to change, thank you sed)
> 2. shift returns with a critical error when no arguments are left (no really
> good solution found)
[ "$#" -eq 0 ] || shift
> 3. $[] arithmetic stuff not working (OK, worked around that with bc)
$((...))
> 4. The bash FUNCNAME variable was very valuable for debugging purposes and is
> nonexistent in dash
If your functions are written as
f() {
...
}
sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/& local
FUNCNAME=\1;/'
--
Stephane
--
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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] echo: fix octal escaping with \1...\7
2011-10-31, 07:35(-06), Paul Gilmartin: > On Oct 31, 2011, at 07:12, Eric Blake wrote: > >> [adding bug-libtool] >> > [removing, because I'm not registered.] > >> On 10/30/2011 10:23 PM, Mike Frysinger wrote: >>> On Sunday 30 October 2011 23:41:58 Herbert Xu wrote: Mike Frysinger wrote: > POSIX states that octal escape sequences should take the form \0num > when using echo. dash however additionally treats \num as an octal > sequence. This breaks some packages (like libtool) who attempt to > use strings with these escape sequences via variables to execute sed > (since sed ends up getting passed a byte instead of a literal \1). >> >> That's a bug in libtool for using "echo '\1'" and expecting sane behavior. >> Can you provide more details on this libtool bug, so we can get it fixed in >> libtool? Or perhaps it has already been fixed in modern libtool, and you >> are just encountering it in an older version? >> > Yes, there's value in coding defensively. However: > > I used to know a statement in POSIX that builtins should behave > identically to the executables in /bin (or perhaps /usr/bin) > except for performance. So, testing with dash on Ubuntu: [...] This can only reasonably be done on systems where the shell and utilities are maintained by the same persons. On my system, /bin/echo '\FS' starts a flight simulator. Should I ask dash to implement that same flight simulator? See also GNU test that doesn't behave the same as GNU bash's "test" (test a \< b for instance). -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] echo: fix octal escaping with \1...\7
2011-10-25, 17:58(-04), Mike Frysinger: > POSIX states that octal escape sequences should take the form \0num > when using echo. Only with the XSI option (Unix), for POSIX, echo "\whatever" is unspecified. But as far as I can tell even with XSI, "echo '\123'" is unspecified as well, so dash is free to do what it likes here. > dash however additionally treats \num as an octal > sequence. This breaks some packages (like libtool) who attempt to > use strings with these escape sequences via variables to execute sed > (since sed ends up getting passed a byte instead of a literal \1). Given that the result of echo "\123" is unspecified, those scripts would not be POSIX and they are those to be fixed. -- Stephane -- 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 http://vger.kernel.org/majordomo-info.html
