[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed features for branching logic + minimal implementation
From: |
Nora Platiel |
Subject: |
Re: proposed features for branching logic + minimal implementation |
Date: |
Fri, 20 Nov 2020 22:37:22 +0100 |
Thanks for the example.
About readability, I think one-liner scripts would benefit the most from
@{...}, while in multi-line scripts you can achieve decent readability with a
well indented t/T:
TL1
...
:L1
Of course, the t/T alternative requires its own label, and numbered labels are
annoying to maintain, but that is a more general issue with sed, not limited to
the t/T command.
When addresses don't cut it we have to use branches, there's no "else" or
"while" equivalent (but sed is simple and powerful for the right use cases
precisely because it doesn't try to do everything).
As I said, I think @ is better than t/T, but that is irrelevant since commands
cannot be removed from sed, obviously.
You used the @ address 8 times, and the J command 5 times.
Currently we are stuck with s/^//;T or tL;:L for resetting the flag. As I said,
I don't like either.
I looked at t/T usage in my own scripts and I noticed that in *all* cases my
intent was for the branch to be determined by the last s-command only. (I
understand that branching on behalf of multiple s-commands may be useful too,
it just never happened to me.)
In your script, the behavior of all but one of the t/@ is determined by the
last s-command only. (The @ after label :0 is affected by two s-commands, is
that intentional?)
Anyway, wanting to branch according to the last s-command only, seems the most
common case to me, so I think some kind of J command would be very useful, even
without the @ address. I wish there were more discussion.
As a side note, I noticed that your script has quoted braces inside bracket
expressions, e.g. [\{\}]. This actually adds the backslash to the list of
characters, and it's equivalent to [{}\].
Regardless of --regexp-extended, a backslash is not special inside [list],
unless it's part of one of the sequences listed here:
https://www.gnu.org/software/sed/manual/sed.html#Escapes