documentation for ${!prefix*} is misleading
The 4.1 man page says:
${!prefix*}
${!pre...@}
Names matching prefix. Expands to the names of variables whose
names begin with prefix, separated by the first character of the
IFS special variable. When @ is used and the expansion appears
within double quotes, each variable name expands to a separate
word.
Actually, the IFS rule only applies when the "${!prefix*}" is quoted.
imadev:~$ IFS='+x'
imadev:~$ echo ${!P*}
P4CLIENT PAGER PATH PIPESTATUS PKG_CONFIG_PATH PPID PS1 PS2 PS4 PWD
imadev:~$ echo "${!P*}"
P4CLIENT+PAGER+PATH+PIPESTATUS+PKG_CONFIG_PATH+PPID+PS1+PS2+PS4+PWD
Or, using a special script to see the arguments more clearly:
imadev:~$ args ${!P*}
10 args:
imadev:~$ args "${!P*}"
1 args:
I believe this is intended behavior (since it matches how $* works),
and that the man page is simply misleading.
Re: documentation for ${!prefix*} is misleading
Greg Wooledge writes:
> The 4.1 man page says:
>
> ${!prefix*}
> ${!pre...@}
>Names matching prefix. Expands to the names of variables whose
>names begin with prefix, separated by the first character of the
>IFS special variable. When @ is used and the expansion appears
>within double quotes, each variable name expands to a separate
>word.
>
> Actually, the IFS rule only applies when the "${!prefix*}" is quoted.
The IFS rules are the same as with $* and $...@.
> imadev:~$ IFS='+x'
> imadev:~$ echo ${!P*}
> P4CLIENT PAGER PATH PIPESTATUS PKG_CONFIG_PATH PPID PS1 PS2 PS4 PWD
${!P*} expands to P4CLIENT+PAGER+PATH+... and word splitting splits it
on any character in $IFS, which echo receives as separate arguments.
Try this to see the difference:
$ o=$IFS; IFS=+; a=${!P*}; IFS=$o; echo $a
> imadev:~$ echo "${!P*}"
> P4CLIENT+PAGER+PATH+PIPESTATUS+PKG_CONFIG_PATH+PPID+PS1+PS2+PS4+PWD
"${!P*}" expands to a single word, no word splitting is performed on it.
> I believe this is intended behavior (since it matches how $* works),
> and that the man page is simply misleading.
Parameter expansion and word splitting are two separate steps. The
quote above only talks about the former.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: documentation for ${!prefix*} is misleading
On Tue, Aug 10, 2010 at 04:15:30PM +0200, Andreas Schwab wrote:
> Greg Wooledge writes:
>
> > The 4.1 man page says:
> >
> > ${!prefix*}
> > ${!pre...@}
> >Names matching prefix. Expands to the names of variables whose
> >names begin with prefix, separated by the first character of the
> >IFS special variable. When @ is used and the expansion appears
> >within double quotes, each variable name expands to a separate
> >word.
> > Actually, the IFS rule only applies when the "${!prefix*}" is quoted.
> > I believe this is intended behavior (since it matches how $* works),
> > and that the man page is simply misleading.
> Parameter expansion and word splitting are two separate steps. The
> quote above only talks about the former.
Eh? The quote mentions the special behavior of the @ version, but not
the special behavior of the * version.
I'd suggest some wording like this:
${!prefix*}
${!pre...@}
Names matching prefix. Expands to the names of variables whose
names begin with prefix. When * is used and the expansion
appears within double quotes, the names are separated by the
first character of the IFS special variable. When @ is used
and the expansion appears within double quotes, each variable
name expands to a separate word.
Re: documentation for ${!prefix*} is misleading
Greg Wooledge writes:
> On Tue, Aug 10, 2010 at 04:15:30PM +0200, Andreas Schwab wrote:
>> Greg Wooledge writes:
>>
>> > The 4.1 man page says:
>> >
>> > ${!prefix*}
>> > ${!pre...@}
>> >Names matching prefix. Expands to the names of variables whose
>> >names begin with prefix, separated by the first character of the
>> >IFS special variable. When @ is used and the expansion appears
>> >within double quotes, each variable name expands to a separate
>> >word.
>
>> > Actually, the IFS rule only applies when the "${!prefix*}" is quoted.
>
>> > I believe this is intended behavior (since it matches how $* works),
>> > and that the man page is simply misleading.
>
>> Parameter expansion and word splitting are two separate steps. The
>> quote above only talks about the former.
>
> Eh? The quote mentions the special behavior of the @ version, but not
> the special behavior of the * version.
There is no special behaviour of the * version.
> I'd suggest some wording like this:
>
>${!prefix*}
>${!pre...@}
> Names matching prefix. Expands to the names of variables whose
> names begin with prefix. When * is used and the expansion
> appears within double quotes, the names are separated by the
> first character of the IFS special variable.
This is wrong. This happens independent of whether it appears within
double quotes. The quotes only make the difference of whether word
splitting can be applied on the expansion (if word splitting is
considered in the first place, which isn't in the case of a variable
assignment, for example).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Issuing re-read-init-file from a Bash function
How do you force a reload of ~/.inputrc from a Bash function ? All "bind re-read-init-file" seems to do is make the [f] key go away. Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/
Re: documentation for ${!prefix*} is misleading
On Tue, Aug 10, 2010 at 04:50:48PM +0200, Andreas Schwab wrote: > There is no special behaviour of the * version. > > The quotes only make the difference of whether word > splitting can be applied on the expansion (if word splitting is > considered in the first place, which isn't in the case of a variable > assignment, for example). Oh... I see now. That's pretty nasty.
Verbatim pasting
Binding printable ASCII characters to readline functions is convenient but it can bite you when you paste text into a shell. Is there a way to bypass readline while pasting ? Something like a ^V toggle or a ^V that lasts until the next newline or next pause between two characters longer than 250 ms or... -- André Majorel http://www.teaser.fr/~amajorel/
Re: Verbatim pasting
On 8/10/10 2:08 PM, Andre Majorel wrote: > Binding printable ASCII characters to readline functions is > convenient but it can bite you when you paste text into a shell. > > Is there a way to bypass readline while pasting ? Something like > a ^V toggle or a ^V that lasts until the next newline or next > pause between two characters longer than 250 ms or... There's nothing like that built in. You can turn off readline with `set +o emacs +o vi', but I can't think of anything more granular right now. 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/
Re: Verbatim pasting
On Tue, Aug 10, 2010 at 2:08 PM, Andre Majorel wrote: > Binding printable ASCII characters to readline functions is > convenient but it can bite you when you paste text into a shell. > > Is there a way to bypass readline while pasting ? Something like > a ^V toggle or a ^V that lasts until the next newline or next > pause between two characters longer than 250 ms or... are you trying to write that text to a file or something ? -mike
Re: Verbatim pasting
Andre Majorel writes: > Binding printable ASCII characters to readline functions is > convenient but it can bite you when you paste text into a shell. This also bites me from time to time when I cut-and-paste a command from an editor window into a bash terminal window. If the line that I cut-and-paste happens to begin with a tab character, then I get a message Display all 3110 possibilities? (y or n) and readline continues to interpret the rest of the line, so if the line contains 'y' or a space before the first 'n' I get at least one screenful of completions. It's mildly annoying. -- "Sanity is not statistical." --George Orwell
Re: Verbatim pasting
On 2010-08-10 16:05 -0400, Mike Frysinger wrote: > On Tue, Aug 10, 2010 at 2:08 PM, Andre Majorel wrote: > > Binding printable ASCII characters to readline functions is > > convenient but it can bite you when you paste text into a shell. > > > > Is there a way to bypass readline while pasting ? Something like > > a ^V toggle or a ^V that lasts until the next newline or next > > pause between two characters longer than 250 ms or... > > are you trying to write that text to a file or something ? I wish I were, I could just type "cat >file" before pasting and ^D after. No, it's just strings, file names, whole command lines, that sort of stuff. -- André Majorel http://www.teaser.fr/~amajorel/
