Re: colored verbose

[lacsaP Patatetom]

Le mer. 8 nov. 2023 à 15:04, alex xmb sw ratchev <fxmbsw7@gmail.com> a
écrit :

>
>
> On Wed, Nov 8, 2023, 3:02 PM lacsaP Patatetom <patatetom@gmail.com> wrote:
>
>> bash's verbose mode makes it possible to "exploit" comments and "preserve"
>> code (pipe characters don't disappear for example)
>>
>
> i dont get it ..
>
> Le mer. 8 nov. 2023 à 13:48, Greg Wooledge <greg@wooledge.org> a écrit :
>>
>> > On Wed, Nov 08, 2023 at 11:26:36AM +0100, lacsaP Patatetom wrote:
>> > > is it possible to distinguish the lines displayed by bash's verbose
>> mode
>> > by
>> > > coloring them ?
>> >
>> > First of all, bash's "verbose mode" is usually worthless.  It is NOT
>> > the same as trace mode (-x).  Usually you want trace mode instead.
>> > However, I'll give you the benefit of the doubt and assume you either
>> > have some compelling need for verbose mode, or that you're clever enough
>> > to replace -v with -x once you realize that's what you really want.
>> >
>> > Now, on to the answer:
>> >
>> > Not as such.  However, we can determine experimentally that "verbose
>> mode"
>> > writes lines to stderr:
>> >
>> > unicorn:~$ bash -v foo >/dev/null
>> > #!/bin/bash
>> > echo hello world
>> > true
>> >
>> > (It's actually undocumented.  Probably because nobody uses verbose mode
>> > or cares about it.  Seriously, trace mode is what you want.  It even
>> > lets you specify a custom FD, so you can intercept *only* trace mode
>> > output, and not ordinary stderr, if that's useful to you.)
>> >
>> > Knowing this, we could set up a filter that intercepts stderr, and adds
>> > colorization around each "line" written there.  Doing this will cause
>> > desynchronization of the stdout and stderr streams, so only do it if
>> > this is not a problem for your script.
>> >
>> > Also, if you don't arrange for the stderr filter to be terminated and
>> > waited for, you may get the next shell prompt before you get the
>> filtered
>> > stderr lines.
>> >
>> > > for example, with this little script, make the first and third
>> displayed
>> > > lines stand out by coloring them :
>> > >
>> > > bash -v <<~~~
>> > > echo hello world
>> > > seq 5
>> > > ~~~
>> > > echo hello world
>> > > hello world
>> > > seq 5
>> > > 1
>> > > 2
>> > > 3
>> > > 4
>> > > 5
>> >
>> > Yeah, see, you are NOT going to get the individual lines of the streams
>> > in the correct order if you do this.  Maybe that's a problem for you,
>> and
>> > maybe it's not.  I dunno.
>> >
>> > Anyway, here's a simplistic implementation to play with:
>> >
>> > ========================================================================
>> > #!/bin/bash
>> > # Set up stderr filtering, and then turn on verbose mode.
>> > filter() {
>> >     local red=$(tput setaf 1)
>> >     local sgr0=$(tput sgr0)
>> >     local line IFS=''
>> >     while read -r line; do
>> >         printf '%s%s%s\n' "$red" "$line" "$sgr0"
>> >     done
>> > }
>> >
>> > exec 2> >(filter >&2)
>> > trap 'exec 2>&-; wait' EXIT
>> > set -v
>> >
>> > # Actual script:
>> > echo hello world
>> > true
>> > ========================================================================
>> >
>> > And running it:
>> >
>> > ========================================================================
>> > unicorn:~$ ./foo
>> > hello world
>> >
>> > # Actual script:
>> > echo hello world
>> > true
>> > exec 2>&-; wait
>> > unicorn:~$
>> > ========================================================================
>> >
>> > Everything from "#" to "wait" is red.  Stderr was delayed by the
>> > filtering, as expected.
>> >
>> > With a slightly different script it becomes a little less terrible:
>> >
>> > ========================================================================
>> > unicorn:~$ ./foo
>> >
>> > (RED) # Actual script:
>> > (RED) sleep 1
>> > hello world
>> > (RED) echo hello world
>> > (RED) sleep 1
>> > good-bye
>> > (RED) echo good-bye
>> > (RED) exec 2>&-; wait
>> > unicorn:~$
>> > ========================================================================
>> >
>> > I added (RED) in front of each colorized line in this example.  When
>> > the commands take longer to run, the desynchronization becomes less
>> > of an issue.  Slightly.  Here's an even better demonstration:
>> >
>> > ========================================================================
>> > unicorn:~$ ./foo
>> >
>> > (RED) # Actual script:
>> > (RED) sleep 1; echo hello world
>> > hello world
>> > (RED) sleep 1; echo good-bye
>> > good-bye
>> > (RED) exec 2>&-; wait
>> > unicorn:~$
>> > ========================================================================
>> >
>> > If *every* line full of commands has a significant delay before it
>> > writes output, then you won't even notice the desynchronization.
>> Anyway,
>> > that's what we've got.  Have fun.
>> >
>> >
>>
>
in debug mode
```
exec 3> >(
 while IFS= read -r xtrace
 do
  printf "## %s ##\\n" "$xtrace"
 done
)
BASH_XTRACEFD=3
set -x
# comment/information
# comment/information
echo foo | tee /dev/null
seq 3
 ```
produces this :
```
## + echo foo ##
## + tee /dev/null ##
foo
## + seq 3 ##
1
2
3
```
and verbose mode
```
set -v
# comment/information
# comment/information
echo foo | tee /dev/null
seq 3
```
produces this :
```
# comment/information
# comment/information
echo foo | tee /dev/null
foo
seq 3
1
2
3
```