[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38661: sed 4.4 : Bogus expression generates an Exception ignored mes
From: |
Assaf Gordon |
Subject: |
bug#38661: sed 4.4 : Bogus expression generates an Exception ignored message |
Date: |
Wed, 18 Dec 2019 13:03:43 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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