[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heredoc leading tab/space behaviour
From: |
Lawrence Velázquez |
Subject: |
Re: Heredoc leading tab/space behaviour |
Date: |
Fri, 24 Jun 2022 15:51:15 -0400 |
User-agent: |
Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7 |
On Fri, Jun 24, 2022, at 9:57 AM, Kerin Millar wrote:
> On Fri, 24 Jun 2022 13:53:07 +0200 (CEST)
> "Ing. Gerold Broser" via Bug reports for the GNU Bourne Again SHell
> <bug-bash@gnu.org> wrote:
>
>> heredoc-error.sh:
>>
>> #!/bin/bash
>> sed -f - heredoc-error.sh <<-SCRIPT
>> ␣␣s/something/else/
>> ⭲ s/more/else/
>> ␣␣SCRIPT
>>
>> $ . heredoc.sh
>> bash: warning: here-document at line 2 delimited by end-of-file (wanted
>> `SCRIPT')
>> sed: file - line 3: unknown command: `S'
>>
>>
>> $ . heredoc-ok.sh
>> #!/bin/bash
>> sed -f - heredoc-ok.sh <<-SCRIPT
>> ␣␣s/else/else/
>> ⭲ s/else/else/
>> ⭲ SCRIPT
It has already been explained that you're mistaken, but I don't
understand how these examples are supposed to demonstrate that
leading spaces have been removed from the input. sed(1) ignores
blank characters before commands.
>> Fix:
>>
>> I think it'd be convenient if Heredoc supports indentation with spaces at
>> the delimiter line, too.
>
> One issue with this proposal is that it would violate the rules of the
> Shell Command Language, per
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04.
Coincidentally, a request to allow <<- to behave this way was
recently submitted. It was rejected within two days, which feels
like it should be some sort of record.
https://austingroupbugs.net/view.php?id=1588
--
vq