Printing in red during output from head

[lisa-asket]

Have managed to do it like this



    find "$fdir" -type f -name "*.org" -o -name "*.texi"  \
      -exec head -n "$n" {} \+                            \
      | sed -e 's/==>/\x1B[01;31m==>/;s/<==/<==\x1B[0m/'


From: Greg Wooledge <greg@wooledge.org>
To: help-bash@gnu.org
Subject: Re: Printing in red during output from head
Date: 21/07/2021 17:59:27 Europe/Paris

On Wed, Jul 21, 2021 at 04:48:03PM +0100, Chris Elvidge wrote:
> On 21/07/2021 02:50 pm, lisa-asket@perso.be wrote:
> > I am almost there, but I am having the problom with the \e
> > 
> > 
> > 
> > find "$fdir" -type f -name "*.org" -o -name "*.texi" \
> > | xargs head -n "$n" \
> > | sed -e 's/==>/^\e[01;31m==>/;s/<==/<==^\e[0m/'
> 
> Instead of typing ^\e, press Ctrl-V and then Esc

This will work, at least in traditional Unix editors, but hard-coding
raw ESC bytes into one's scripts is considered bad form. There's a risk
that whatever editor lisa-asket is using won't be able to handle it.

It's also *ugly*. It's difficult for someone reading the program to
figure out what the code does or why there's an unprintable byte in
the middle of the line. The actual difficulty will depend both on the
reader's experience level with this style of coding, and the editor or
pager that was used to view the code. In the worst cases, e.g. if they
simply used "cat", the entire escape sequence might be rendered invisible
and part of the code will simply turn red, or other unpredictable results
may occur, e.g. if they're not on a terminal which understands this
escape sequence in the same way as the author's terminal(s).

Thus, there's the desire to represent the ESC byte with some sort of
printable glyphs -- either \033 or \e, for example.

The trick is deciding which program is going to be responsible for
converting those glyphs into the raw ESC byte for sed to see. Maybe
sed itself can do that -- that sound like something GNU sed might do,
for example, although I don't know whether that's actually true, or if
it is true, how portable it would be across sed implementations.

Another choice would be to let bash do the conversion, by using the $'...'
quoting form, instead of the '...' quoting form, around the sed program.
That's the direction I'd recommend, if we can't convince the OP to drop
this approach (or even this *goal*) altogether.