bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 1/2] <<# indent-stripping heredoc


From: Grisha Levit
Subject: [PATCH 1/2] <<# indent-stripping heredoc
Date: Thu, 13 Jul 2023 19:47:53 -0400

This patch implements the ksh93-style <<# redirection operator to
enable indentatable heredocs.  This (or similar) functionality has
been requested a few times, most recently discussed at
https://lists.gnu.org/archive/html/bug-bash/2021-09/msg00000.html

The behavior for heredocs started with the <<# redirection operator is:

* Any leading blank characters on the first line of the heredoc define
the indentation of the heredoc
* Tab characters in indentation are interpreted as indenting to the
next 8-column-wide tab stop
* All lines of the heredoc are stripped of (up to) as many columns of
indentation as found on the first line
* The heredoc is terminated when, after any indentation has been
removed, the remaining line exactly matches the delimiter

There is a small (and not very interesting) edge case: if the heredoc
delimiter itself has leading blanks (e.g. <<# " EOF"), then the first
line cannot terminate the heredoc (even if it exactly matches the
delimiter) because any leading blanks on the first line are treated as
defining the heredoc's indentation and so cannot form part of the
line.  This matches the ksh93 behavior.

As pointed out by Lawrence Velázquez in the last discussion, <<# is
currently a syntax error except for the case of `shopt -u
interactive_comments' in an interactive shell.  I don't think it's
likely that users are turning off interactive comments and starting
heredoc delimiters with `#' but it would be a trivial change to the
code to not recognize <<# docs in that circumstance, should we want to
go that route.

Attachment: 0001-indent-stripping-heredoc.patch
Description: Binary data


reply via email to

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