(bash) What is the difference between << and <<<, from a functionality
POV? I.e., is there anything you can do with one but not the other?

I'm talking about this:

$ cmd << 'EOF'
....
....
EOF
$

vs.

$ cmd <<< '
....
....
'
$

Of course I know, as does everybody, that << is legacy and <<< is new, but
it begs the question: Why was <<< added to the language?

Note that I use both constructs, as the mood suits me, but I just got to
thinking that maybe <<< doesn't actually add any new functionality.

--
Adderall, pseudoephed, teleprompter

On 17.09.2024 07:37, Kenny McCormack wrote:
> (bash) What is the difference between << and <<<, from a functionality
> POV? I.e., is there anything you can do with one but not the other?
>
> I'm talking about this:
>
> $ cmd << 'EOF'
> ...
> ...
> EOF
> $
>
> vs.
>
> $ cmd <<< '
> ...
> ...
> '
> $
>
> Of course I know, as does everybody, that << is legacy and <<< is new, but
> it begs the question: Why was <<< added to the language?

The '<<<' is basically only a convenience syntax for one-liners.

When it had (first) been introduced by Kornshell there was a slight
difference between the two, '<<' and '<<<'; IIRC, the '<<<' did not
create a '\n'. (I had discussed the feature with DGK the days when
it had been introduced. The result, DGK's decision, is what you see.)

>
> Note that I use both constructs, as the mood suits me, but I just got to
> thinking that maybe <<< doesn't actually add any new functionality.

It's actually a restriction since it doesn't allow (e.g.) to control
variable expansion (as is possible with escaping the tag ('EOF' in
your example, which prevents exüpansion, vs. unquoted/unescaped EOF ).

And, of course, Kornshell allows yet more control features with '<<';
see its man-page for the '<<#' variant.

Janis

In article <vcbb68$3dfds$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>> Note that I use both constructs, as the mood suits me, but I just got to
>> thinking that maybe <<< doesn't actually add any new functionality.
>
>It's actually a restriction since it doesn't allow (e.g.) to control
>variable expansion (as is possible with escaping the tag ('EOF' in
>your example, which prevents expansion, vs. unquoted/unescaped EOF ).

Well, not really. I can always do:

$ cmd << EOF
$(fortune)
EOF
$

and/or:

$ cmd <<< "
$(fortune)
"
$

Same diff, innit?

--
They say that Trump is a stupid man's idea of a clever man, a poor man's
idea of a rich man, and a weak man's idea of a strong man.

Well, Melania is an unclassy man's idea of classy.

On 17.09.2024 15:10, Kenny McCormack wrote:
> In article <vcbb68$3dfds$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>> Note that I use both constructs, as the mood suits me, but I just got to
>>> thinking that maybe <<< doesn't actually add any new functionality.
>>
>> It's actually a restriction since it doesn't allow (e.g.) to control
>> variable expansion (as is possible with escaping the tag ('EOF' in
>> your example, which prevents expansion, vs. unquoted/unescaped EOF ).
>
> Well, not really. I can always do:

Ah, of course!

So what remains then is only '<<<' being a one-liner shortcut and
the '<<-' (plus the '<<#' in ksh) features to control indentation,
I suppose.

Janis

>
> $ cmd << EOF
> $(fortune)
> EOF
> $
>
> and/or:
>
> $ cmd <<< "
> $(fortune)
> "
> $
>
> Same diff, innit?
>

In article <vcc7qk$3j1r6$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>So what remains then is only '<<<' being a one-liner shortcut and
>the '<<-' (plus the '<<#' in ksh) features to control indentation,
>I suppose.

Now, I wonder about the actual implementation. In early versions of the
Bourne shell, using << actually created a temp file somewhere (perhaps in /tmp),
which raises the specter of that file not getting removed in crash scenarios.

I don't suppose that is still a cause for concern. What about <<<? How is
that implemented?

--
"Unattended children will be given an espresso and a free kitten."

In article <vcc7qk$3j1r6$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>So what remains then is only '<<<' being a one-liner shortcut and
>the '<<-' (plus the '<<#' in ksh) features to control indentation,
>I suppose.

I just thought of something. Suppose your included text contains both
single and double quotes. This will not be an issue with <<, but will
require extra effort (more than I care to expend!) with <<<.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

On 17.09.2024 17:54, Kenny McCormack wrote:
> In article <vcc7qk$3j1r6$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>> So what remains then is only '<<<' being a one-liner shortcut and
>> the '<<-' (plus the '<<#' in ksh) features to control indentation,
>> I suppose.
>
> I just thought of something. Suppose your included text contains both
> single and double quotes. This will not be an issue with <<, but will
> require extra effort (more than I care to expend!) with <<<.

That's actually the property I like with here-docs; that you can
write your template-like text inside the shell-program text as it
shall (and will) be seen at the target side, both forms of quotes
inclusive.

As might have already got obvious, though, I use the '<<<' syntax
for other purposes than for such template files; for one-liners. In
that context mixed quote forms are not typical (IME) so that this
property of '<<' is not that important for me to have in '<<<'.[*]

Janis

[*] Such a quote-mixture seems to appear mostly in longer text that
I anyway generally implement with '<<' (if only for its additional
feature to control indentation and thereby make the whole text more
legible).

On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Note that I use both constructs, as the mood suits me, but I just got to
> thinking that maybe <<< doesn't actually add any new functionality.

It rearranges the syntax so that the data whicha are destined for a
command's standard input are presented in the command line, rather
than as extra lines in the shell script below the command line.

Consider that we have two cat commands in a single command line. How do
we feed them here docs? They have to be extraposed after the entire
command line:

cat <<! ; cat <<!
foo
!
bar
!

The left cat gets foo, the right cat gets bar. This is kind of gross.
It reminds you of READ statements in BASIC which look for DATA
later in the program.

Also, think of the pains people go through to indent here docs
nicely when they occur in nested code.

Suppose you have some multi-line text in a variable "var", and would
like to pipe that text into a command (and nothing but that text).
It's obviously nicer to just do cmd <<<$var rather than

cmd <<!
$var
!

Moreover, I think, the latter will send an extra newline to the
command. If the last line in $var already has a newline, that
results in a spurious blank line, am I right?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <vccesq$3kjv7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>> I just thought of something. Suppose your included text contains both
>> single and double quotes. This will not be an issue with <<, but will
>> require extra effort (more than I care to expend!) with <<<.
>
>That's actually the property I like with here-docs; that you can
>write your template-like text inside the shell-program text as it
>shall (and will) be seen at the target side, both forms of quotes
>inclusive.

Right. The point I was making is that this rates as a superiority of <<
over <<< - and answers the question posted in the OP: Is there anything one
can do that the other cannot?

>As might have already got obvious, though, I use the '<<<' syntax
>for other purposes than for such template files; for one-liners. In
>that context mixed quote forms are not typical (IME) so that this
>property of '<<' is not that important for me to have in '<<<'.[*]

Right. Got it.

--
Politics is show business for ugly people.

Sports is politics for stupid people.

On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <vccesq$3kjv7$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>> I just thought of something. Suppose your included text contains both
>>> single and double quotes. This will not be an issue with <<, but will
>>> require extra effort (more than I care to expend!) with <<<.
>>
>>That's actually the property I like with here-docs; that you can
>>write your template-like text inside the shell-program text as it
>>shall (and will) be seen at the target side, both forms of quotes
>>inclusive.
>
> Right. The point I was making is that this rates as a superiority of <<
> over <<< - and answers the question posted in the OP: Is there anything one
> can do that the other cannot?

Many years ago, I was working on an embedded Linux distro (from
scratch). For text files installed on the target system, like /etc,
I had a Makefile-based thing which could preprocess files with several
preprocessors, based on their suffix. One of the preprocessors was
shell. For those files, what the Makefile did was dynamically
generate a temporary script like this:

cat <<ENDMARKER
# pasted copy of the template file here
ENDMARKER

and then execute the temporary script.

What I'm getting at is that nothing had to be done to the template
file text.

If <<< is used, then the whole template is a quoted field, using
either single quotes and double quotes.

We cannot generate this:

cat <<<'
# pasted copy of the template file here
'

Because the template file could contain single quotes, which would
have to be turned into '\''.

Similarly, we cannot blindly generate this:

cat <<<"
# pasted copy of the template file here
"

because double quotes need escaping now. This is the variant we
would have to use in the templating system because the template
files relied on interpolating the output of variables and
shell commands:

$(for x in a b c; do echo blah $x; done)

So in fact this is backwards; the <<< syntax can likely produce
all the output that << can, but it requires quoting, which requires
escaping that << does not require.

E.g. we can do this:

$ cat <<!
'$USER
!
'kaz

There is an unbalanced quote there, which is just a verbatim
character. Not a problem in a here-doc.

In this sense, the <<< syntax does less: it requires quoting, which
protects fewer character sequences from being interpeted specially. It
does so for the benefit of its inline syntax.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <20240917132221.49@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <vccesq$3kjv7$1@dont-email.me>,
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> ...
>>>> I just thought of something. Suppose your included text contains both
>>>> single and double quotes. This will not be an issue with <<, but will
>>>> require extra effort (more than I care to expend!) with <<<.
>>>
>>>That's actually the property I like with here-docs; that you can
>>>write your template-like text inside the shell-program text as it
>>>shall (and will) be seen at the target side, both forms of quotes
>>>inclusive.
>>
>> Right. The point I was making is that this rates as a superiority of <<
>> over <<< - and answers the question posted in the OP: Is there anything one
>> can do that the other cannot?
>
>Many years ago, I was working on an embedded Linux distro (from
>scratch). For text files installed on the target system, like /etc,
>I had a Makefile-based thing which could preprocess files with several
>preprocessors, based on their suffix. One of the preprocessors was
>shell. For those files, what the Makefile did was dynamically
>generate a temporary script like this:

Perhaps you misread my post. Perhaps you misread "superiority" as
"inferiority". I admit that the two words do look pretty similar.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20240917132221.49@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> In article <vccesq$3kjv7$1@dont-email.me>,
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> ...
>>>>> I just thought of something. Suppose your included text contains both
>>>>> single and double quotes. This will not be an issue with <<, but will
>>>>> require extra effort (more than I care to expend!) with <<<.
>>>>
>>>>That's actually the property I like with here-docs; that you can
>>>>write your template-like text inside the shell-program text as it
>>>>shall (and will) be seen at the target side, both forms of quotes
>>>>inclusive.
>>>
>>> Right. The point I was making is that this rates as a superiority of <<
>>> over <<< - and answers the question posted in the OP: Is there anything one
>>> can do that the other cannot?
>>
>>Many years ago, I was working on an embedded Linux distro (from
>>scratch). For text files installed on the target system, like /etc,
>>I had a Makefile-based thing which could preprocess files with several
>>preprocessors, based on their suffix. One of the preprocessors was
>>shell. For those files, what the Makefile did was dynamically
>>generate a temporary script like this:
>
> Perhaps you misread my post. Perhaps you misread "superiority" as
> "inferiority". I admit that the two words do look pretty similar.

No I didn't misread; but that's what it is. While the <<<
syntax represents a certain kind of improvement in that it doesn't
require weird parsing (line-oriented fetching of data that is out of
band with regard to the phrase structure syntax of the shell language),
it has disadvantages due to the increased complexity of quoting.

If you want to produce some templated text with shell interpolation,
with minimal uncertainties with regard to quoting, <<< is in fact
inferior.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Perhaps you misread my post. Perhaps you misread "superiority" as
> "inferiority". I admit that the two words do look pretty similar.

Here is a superiority. Because the <<< construct uses the ordinary
expansions in a command line, it is useful in a situation in which we
have an existing command that takes some complicated expansion as an
argument, and we would like to use that as standard input. The <<<
construct lets us do that without having to convert everything in that
complicated expansion into a here document.

It's not that we can't convert that content it to a here document, but
it takes work, and could introduce a bug.

So it's just tradeoffs. Some aspect that is an advantage in one
situation is a disadvantage in another, and so it goes.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <20240917140842.283@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
....
>If you want to produce some templated text with shell interpolation,
>with minimal uncertainties with regard to quoting, <<< is in fact
>inferior.

You really might want to go back and check up on your reading skills.

Note: We are in violent agreement.

--
People who say they'll vote for someone else because Obama couldn't fix
*all* of Bush's messes are like people complaining that he couldn't cure
cancer, so they'll go and vote for (more) cancer.

On 2024-09-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20240917140842.283@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> ...
>>If you want to produce some templated text with shell interpolation,
>>with minimal uncertainties with regard to quoting, <<< is in fact
>>inferior.
>
> You really might want to go back and check up on your reading skills.

I really don't understand the point of this remark.

Yes, it's clear you wanted to know if an extension in Bash does
something that strictly can't be done with its standard cousin.

In the computational sense, it almost certainly does not enable the
calculation of output texts that are not out of reach to <<.

It does express things differently such that some things that can
be done /in a certain way/ with one thing cannot be with the other
and vice versa.

> Note: We are in violent agreement.

Not only that, but it doesn't even look like anything has been posited
in disagreeing terms or that anyone (visible to me) thinks there is a
disagreement.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca