Re: empty lines at the end of quoted command subsitutions missing
koe...@science-computing.de writes: > empty line(s) at the end of quoted command subsitutions are missing: That is not a bug, but a feature. Command subsitution generally strips trailing newlines from the output of the command. If you want the complete output use a pipe. 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: empty lines at the end of quoted command subsitutions missing
On Sat, Jul 24, 2010 at 10:23 AM, Andreas Schwab wrote:
> koe...@science-computing.de writes:
>
>> empty line(s) at the end of quoted command subsitutions are missing:
>
> That is not a bug, but a feature. Command subsitution generally strips
> trailing newlines from the output of the command. If you want the
> complete output use a pipe.
>
It's probably intuitively what you expect when you do
var=$(echo a); echo "$var"
In this case most people would expect 1 newline and not 2
(one from the first echo in $( ) and the second from the second echo)
You can also use a trick like: var=$(command;printf e) var=${var%e}
Re: empty lines at the end of quoted command subsitutions missing
On 7/24/10 3:23 AM, Andreas Schwab wrote: > koe...@science-computing.de writes: > >> empty line(s) at the end of quoted command subsitutions are missing: > > That is not a bug, but a feature. Command subsitution generally strips > trailing newlines from the output of the command. If you want the > complete output use a pipe. This is one of the reasons I added `printf -v' to supplement v=$(command). 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: words in COMPWORDS vs. words in COMPREPLY
On 7/20/10 3:14 PM, Ben Pfaff wrote:
> I'm trying to learn how bash completion works, so that I can
> write completion functions for some utilities.
>
> As an experiment, I wrote the following trivial completion. It
> is intended to report that the completions for the current word
> are exactly the contents of the current word:
>
> _test () {
> COMPREPLY=(${COMP_WORDS[COMP_CWORD]})
> }
> complete -F _test test
>
> I expected that, with the above, typing "test", followed by a
> word, followed by , would cause bash just to insert a space.
> This is often what happens, but I've found some exceptions that I
> do not yet understand. For example, consider the following:
> test x=
>
> When I press , I expected this to expand to:
> test x=
> followed by a space.
> With Debian's bash 4.1-3 (on which bash --version reports
> "version 4.1.5(1)-release"), this actually expands as:
> test x==
> followed by a space.
>
> With Debian's bash 3.2-4 ("bash 3.2.39(1)-release"), this expands
> as:
> test x=x=
> followed by a space.
Since `=' is one of the characters readline uses to break words for the
completer, ${COMP_WORDS[$COMP_CWORD]} expands to `='. It's treated as
a separate word on the line.
One of the changes between bash-3.2 and bash-4.0 was to make the
programmable completion code use the same set of characters as readline
to break the line into words:
i. The programmable completion code now uses the same set of characters as
readline when breaking the command line into a list of words.
This explains the behavior difference between bash-3.2 and bash-4.1.
If you want to remove `=' from the set of characters used to break words
for completion, modify the COMP_WORDBREAKS variable.
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/
