Prev: MD5 checksums from downloaded pdfs to prevent duplication
Next: read command not waiting at pause prompt
From: Florian Kaufmann on 21 Apr 2008 06:58
Sorry - I don't get it to work. There shouldn't be any empty lines
anywhere.
From: pk on 21 Apr 2008 07:03
On Monday 21 April 2008 12:54, Florian Kaufmann wrote:

>> Well, since the <<< construct accepts strings *only on the same line*, I
>
> Why you think is that so?
>
> $ cat <<< 'hello
>> test'
> hello
> test

Ok, sorry, bad wording. I meant the construct accepts only a single string,
which may contain newlines of course. Still, since there is no explicit
ending delimiter (unlike in <<), I think it would be difficult, with the
current syntax, for the shell to understand whether the user wants the
trailing \n or not.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.
From: pk on 21 Apr 2008 07:11
On Monday 21 April 2008 13:03, pk wrote:

> Ok, sorry, bad wording. I meant the construct accepts only a single
> string, which may contain newlines of course. Still, since there is no
> explicit ending delimiter (unlike in <<), I think it would be difficult,
> with the current syntax, for the shell to understand whether the user
> wants the trailing \n or not.

And, what the OP wants is not possible with the traditional here-document
(<<) either, despite the explicit terminator, since it must be on a single
line by itself, and thus the previous line must end with a \n.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.
First  |  Prev  | 
Pages: 1 2
Prev: MD5 checksums from downloaded pdfs to prevent duplication
Next: read command not waiting at pause prompt