bug-bash
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]