bug#38661: sed 4.4 : Bogus expression generates an Exception ignored message

[Assaf Gordon]

tag 38661 notabug
close 38661
stop

Hello,

On 2019-12-18 3:48 a.m., Alejandro Torras wrote:
> I've been hit by an 'Exception ignored' message while working on the following 
> bogus sed expression:
>
> $ lsb_release -d | sed -E -e 's:^[^:]+:[\t ]*(.*):\1:'
> sed: -e expression #1, char 21: unknown option to `s'
> Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' 
> encoding='UTF-8'>
> BrokenPipeError: [Errno 32] Broken pipe

[...]

> IMHO I think the "Exception ignored" message should not be raised, as it's 
> caused by a formal error in the syntax and it was correctly reported before.
> Could you give it a sight?

This is not a bug in 'sed', and perhaps not a bug at all.

The first message ("sed: -e expression #1...") is indeed generated by
sed. The other two messages ("Exception ignored..." and
"BrokenPipeError") are generated by "lsb_release".

They all appear on the terminal because programs running like that
on the command-line share their "standard error" (stderr) pipe.
All errors (from any program in the pipeline) will be displayed on the
screen.

You can see this by running each program separately:

  $ sed -E -e 's:^[^:]+:[\t ]*(.*):\1:'
  sed: -e expression #1, char 21: unknown option to `s'

  $ lsb_release -d | false
  Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' 
encoding='UTF-8'>
  BrokenPipeError: [Errno 32] Broken pipe

In the example above, the "false" program is used as a dummy that
exits immediately and does not read any input sent by "lsb_release".
This causes the "lsb_release" program to complain about the broken pipe.

Whether you consider this "broken pipe" error a bug or not is a matter
of opinion - but that's the way the program behaves.

---

As a side note, the sed command you are using seems a bit convoluted,
and perhaps can be improved?

First,
Using "s:xxx:yyy:" means that the colons are the regex separator
character, just like slashes in the more common "s/xxx/yyy/".
But in your case, colons are also important in the regex itself -
so using them causes more confusion (and leads to the sed error).

This would be better:
  sed -E 's/^[^:]+:[\t ]*(.*)/\1/'



Second,
GNU sed has a a special operator "\s" which means any space
character, which could replace the '[\t ]' :

  sed -E 's/^[^:]+:\s*(.*)/\1/'


Third,
Since you want to remove the prefix (before the first colons ":")
and keep everything after it, the regex could be simplified to:

  sed -E 's/^[^:]*:\s*//'


Fourth,
Based on the specification of "lsb_release" 
(https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html 
),
the output will be:
   Description:\t<Description>

If we can assume that the description string content does not contain
colons followed by a tab (which might or might not be a reasonable 
assumption), the regex could be ever further simplified to:

   lsb_release -d | sed 's/.*:\t//'



Last but not least,
"lsb_release" has a "-s/--short" option,
which only outputs the value, alleviating any need for sed :)

   $ lsb_release -ds
   Debian GNU/Linux 10 (buster)



Hope this helps.
I'm closing this as "not a bug", but discussion can continue
by replying to this thread.

- assaf