Re: More fun with IFS
On Wednesday, January 30, 2013 02:00:26 AM Chris F.A. Johnson wrote:
> On Wed, 30 Jan 2013, Dan Douglas wrote:
>
> > Hi everyone, and welcome to another edition of IBOTD (IFS-bug-of-the-day),
> > featuring everyone's favorite Bourne shell kludge: word-splitting!
> >
> > On today's episode - inconsistencies within assignments that depend upon
> > quoting. I can't take credit for discovering this -- it was pointed out
> > to me by some guys on IRC after demonstrating some other stuff.
> >
> > And a quick test:
> >
> > function expassign {
> > typeset -a a
> > a=("$@")
> > typeset var asn
> >
> > while IFS= read -r asn; do
> > IFS=: command eval "$asn"
> > printf '%-14s... %s\n' "$asn" "$var"
> > done <<\EOF
> > var=${a[*]}
> > var="${a[*]}"
> > var=$*
> > var="$*"
> > var=${a[@]}
> > var="${a[@]}"
> > var=$@
> > var="$@"
> > EOF
> > }
> >
> > ${ZSH_VERSION+:} false && emulate ksh
> > expassign one:::two three:::four
> >
> > Bash output: # I think...
> > var=${a[*]} ... one two three four # bad
>
> Looks good to me. It expands to multiple words, just as an unquoted
> $* would do.
No, $* always expands to a single word. If multiple words result, those are
the result of field-splitting, not an intrinsic multi-word expansion as in the
case of $@. Though POSIX says very little about the unquoted cases.
Secondly, at least one of these would almost have to be wrong unless it
somehow makes sense for $* and ${a[*]} to be treated differently (it doesn't).
Third, field-splitting doesn't occur within assignments so quoting shouldn't
matter here.
I'll grant that POSIX is extremely unclear about whether and when multiple
words are actually the result of a multi-word expansion, or a field splitting
step. It gets much worse when it comes to the alternate-value expansions where
it's then additionally unclear whether and how word-splitting and/or the
implicit multi-wordness of $@ occur recursively when nested (or not). Almost
all shells disagree on that, but I need to do more research for those cases
because it's hard to test what's going on. ksh93 is especially bizarre in its
nested expansions.
> > var="${a[*]}" ... one:::two:three:::four # good
> > var=$*... one:::two:three:::four # good
> > var="$*" ... one:::two:three:::four # good
> > var=${a[@]} ... one two three four # bad
>
> As above.
No, the ::: shouldn't be removed here. The * and @ cases are separate issues
(I should have been clear that there are multiple problems going on).
> > var="${a[@]}" ... one:::two three:::four # good
> > var=$@... one two three four # bad
>
> Ditto.
>
> > var="$@" ... one:::two three:::four # good
> >
> > Zsh and pdkshes produce:
> >
> > one:::two:three:::four
> >
> > For all of the above, which I think is wrong for the last 4. ksh93
produces:
> >
> > one:::two three:::four
> >
> > for the last 4, which I think is correct.
> >
> >
>
>
--
Dan Douglas
Re: More fun with IFS
On Wed, 30 Jan 2013, Dan Douglas wrote:
Hi everyone, and welcome to another edition of IBOTD (IFS-bug-of-the-day),
featuring everyone's favorite Bourne shell kludge: word-splitting!
On today's episode - inconsistencies within assignments that depend upon
quoting. Though I can't take credit for discovering this -- it was pointed out
to me by some guys on IRC after demonstrating some other stuff.
And a quick test:
function expassign {
typeset -a a
a=("$@")
typeset var asn
while IFS= read -r asn; do
IFS=: command eval "$asn"
printf '%-14s... %s\n' "$asn" "$var"
done <<\EOF
var=${a[*]}
var="${a[*]}"
var=$*
var="$*"
var=${a[@]}
var="${a[@]}"
var=$@
var="$@"
EOF
}
${ZSH_VERSION+:} false && emulate ksh
expassign one:::two three:::four
Bash output: # I think...
var=${a[*]} ... one two three four # bad
Looks good to me. It expands to multiple words, just as an unquoted
$* would do.
var="${a[*]}" ... one:::two:three:::four # good
var=$*... one:::two:three:::four # good
var="$*" ... one:::two:three:::four # good
var=${a[@]} ... one two three four # bad
As above.
var="${a[@]}" ... one:::two three:::four # good
var=$@... one two three four # bad
Ditto.
var="$@" ... one:::two three:::four # good
Zsh and pdkshes produce:
one:::two:three:::four
For all of the above, which I think is wrong for the last 4. ksh93 produces:
one:::two three:::four
for the last 4, which I think is correct.
--
Chris F.A. Johnson,
More fun with IFS
Hi everyone, and welcome to another edition of IBOTD (IFS-bug-of-the-day),
featuring everyone's favorite Bourne shell kludge: word-splitting!
On today's episode - inconsistencies within assignments that depend upon
quoting. Though I can't take credit for discovering this -- it was pointed out
to me by some guys on IRC after demonstrating some other stuff.
And a quick test:
function expassign {
typeset -a a
a=("$@")
typeset var asn
while IFS= read -r asn; do
IFS=: command eval "$asn"
printf '%-14s... %s\n' "$asn" "$var"
done <<\EOF
var=${a[*]}
var="${a[*]}"
var=$*
var="$*"
var=${a[@]}
var="${a[@]}"
var=$@
var="$@"
EOF
}
${ZSH_VERSION+:} false && emulate ksh
expassign one:::two three:::four
Bash output: # I think...
var=${a[*]} ... one two three four # bad
var="${a[*]}" ... one:::two:three:::four # good
var=$*... one:::two:three:::four # good
var="$*" ... one:::two:three:::four # good
var=${a[@]} ... one two three four # bad
var="${a[@]}" ... one:::two three:::four # good
var=$@... one two three four # bad
var="$@" ... one:::two three:::four # good
Zsh and pdkshes produce:
one:::two:three:::four
For all of the above, which I think is wrong for the last 4. ksh93 produces:
one:::two three:::four
for the last 4, which I think is correct.
--
Dan Douglas
Re: Short list of issues with various expansions and IFS
Hey thanks for all the nice explanations. I'm sure I'll reference this in the future. > > 3. Another IFS oddity via "command" > > > > IFS can be given "two values at once" through the environment of a > > redirection. > > I have to look at this one. It's clear that the temporary environment > given to `command' is like the temp environment supplied to `eval', and > needs to persist through all of the commands executed by `command'. I > have to figure out whether that temporary environment counts as the temp > environment to `cat' (I don't think so) and how to reconcile the variable > lookups during redirection expansion. I think at least the variable should be accessible to builtins or functions run by `command' (if not cat). Maybe you meant it doesn't actually get exported to non-builtins? In this case, the redirect should be applying to the `command' command, so the outer environment is what applies to the redirect just like any other normal command (I think). I forgot to mention also that related to this issue, Bash is the only shell that does word-splitting on here-strings in the first place. The others treat the words expanded after the redirect as in an unquoted here-document, except with quote-removal despite having no wordsplitting or globbing (while in a heredoc, there's no quote removal either). So Bash for instance will trim whitespace down to 1 space if you don't quote herestring contents, while others don't, and treat the herestring almost exactly like the word following `in' in a case..esac. There's also a documentation bug related to this: "The word following the redirection operator in the following descriptions, unless otherwise noted, is subjected to brace expansion, tilde expansion, parameter expansion, command substitution, arithmetic expansion, quote removal, pathname expansion, and word splitting. If it expands to more than one word, bash reports an error." Here-strings are of course an exception to the last sentence, and possibly an exception to parts of the previous sentence (here-strings are defined in terms of the here-document, which might make the issue not so straightforward). -- Dan Douglas
Re: interrupted system call when using named pipes on FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/13 1:30 AM, Mike Frysinger wrote: > this is somewhat a continuation of this thread: > http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html > > i've gotten more or less the same report in Gentoo: > http://bugs.gentoo.org/447810 > > the simple test case is: > $ cat test.sh > #!/bin/bash > while :; do > (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& > while read x ; do : ; done < <(echo foo) > done > > execute `./test.sh` and we see failures pretty much all the time. I did some looking around, and the script does result in open returning - -1/EINTR, even if SIGCHLD is installed with SA_RESTART, on FreeBSD and Mac OS X. It doesn't happen on RHEL 5. I may test Solaris 11 later. I did find a reference to the Linux kernel patch that makes this work: http://marc.info/?l=linux-kernel&m=134071285509470 Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEIRk8ACgkQu1hp8GTqdKvk/QCfQ+bl09en7Yonmj+0+Vqhjvlk 7ykAn00mDwdQT5hTD9L7z/GN+8NFMTzS =wKJk -END PGP SIGNATURE-
Re: backward-line
On 1/28/13 6:07 PM, Egmont Koblinger wrote: > Do you guys like this feature, do you think it could make it into official > bash? > > If so, let me come up with a proper patch (it's going to be much more > complicated in order to support double wide characters. The current one is > just a quick demo of the proposed feature which only works correctly with > single-cell characters.) Sure, I'd be willing to put a complete patch to add this feature into Readline. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
[PATCH] display bug in multi-line command when a utf-8 is shifted to next line
Hi, In UTF-8 environment, with bash-4.2.42, type a command that takes up at least 3 lines, and contains an accented (UTF-8) letter in the first line. Move the cursor to the beginning, and insert more characters. Just when the UTF-8 accented letter is pushed down to the second line, the last line becomes displayed incorrectly: its last letter is doubled. Same when you delete chars so that the accented one jumps back to the previous line. Updating the last line uses the macro VIS_LLEN to determine the length of that line in the 'old' buffer, which in turn accesses the vis_lbreaks array up to the index ind_botlin+1. When the UTF-8 character overflows, the 'old' buffer is modified and vis_lbreaks is supposed to be adjusted correctly, however, due to the premature end of the loop this last value is not updated. Please apply the attached trivial patch to fix the problem. Thanks, egmont bash-4.2.42-last-line-misdrawn-after-char-insertion.patch Description: Binary data
