Where does the trailing "/n" come from?

------------------------------------------------------------ ---------------
$cat <<<'Mary has a little lamb!'
Mary has a little lamb!

------------------------------------------------------------ ---------------
There is an unexpected '\n' in the end. Unlike echo, cat won't output
a
after the string. So where does the trailing '\n' come from? Maybe it
is related
to the Here String. But it is not mentioned in the bash manual.

Best Regards,
PRC
Apr 21, 2008

Re: Where does the trailing "/n" come from?

In article
<1c675e01-8ead-491d-840f-a5b9192d67fe@u12g2000prd.googlegroups.com>,
PRC wrote:

> ------------------------------------------------------------ ---------------
> $cat <<<'Mary has a little lamb!'
> Mary has a little lamb!
>
> ------------------------------------------------------------ ---------------
> There is an unexpected '\n' in the end. Unlike echo, cat won't output
> a
> after the string. So where does the trailing '\n' come from? Maybe it
> is related
> to the Here String. But it is not mentioned in the bash manual.

Sounds like a bug in the man page. Most programs expect text input to
be newline-terminated, and it would be a pain if you always had to
include an explicit newline in here strings, so the newline is added
automatically.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: Where does the trailing "/n" come from?

On Monday 21 April 2008 06:50, PRC wrote:

> ------------------------------------------------------------ ---------------
> $cat <<<'Mary has a little lamb!'
> Mary has a little lamb!
>
> ------------------------------------------------------------ ---------------
> There is an unexpected '\n' in the end. Unlike echo, cat won't output
> a after the string. So where does the trailing '\n' come from?
> Maybe it is related to the Here String. But it is not mentioned in the
> bash manual.

Well, since the <<< construct accepts strings *only on the same line*, I
think the \n is implied, since it would be difficult to differentiate the
case where it's wanted and where it's not.
However, it seems you are using bash, so I think you can use something like

cat <(printf "%s" "Mary had a little lamb")

to achieve the same result. Or, of course, just

printf "%s" "Mary had a little lamb"

--
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.

Re: Where does the trailing "/n" come from?

> Well, since the <<< construct accepts strings *only on the same line*, I

Why you think is that so?

$ cat <<< 'hello
> test'
hello
test
$ $0 --version
GNU bash, version 3.2.33(18)-release (i686-pc-cygwin)
Copyright (C) 2007 Free Software Foundation, Inc.

Re: Where does the trailing "/n" come from?

The previous post was mysteriously ill formated.

$ cat <<< 'hello
> test'
hello
test

Re: Where does the trailing "/n" come from?

Sorry - I don't get it to work. There shouldn't be any empty lines
anywhere.

Re: Where does the trailing "/n" come from?

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.

Re: Where does the trailing "/n" come from?

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.