A couple of days ago, I sent a bug report to address@hidden,
but it was late enough at night that I did a bad job of explaining
what was wrong. I also forgot to include the word "sed" in the
subject line.
Here's take 2:
- I'm using sed to filter a log, before passing it to the next
part of a shell script
- It appears that sed's "t" command doesn't work properly under
some situations
- The log file's format is almost identical to JSON:
- {
property: "value",
property2: "value",
...
lastproperty: "value"
}
{
property_of_next_entry: "value",
...
- The sed script does 2 things:
- Block any invalid entries
- Transform the log's data into a format that's easy for a
shell script to process:
property_name,value
- sed options:
sed -nrf log-filter.sed
- sed version:
GNU sed 4.2.2
- uname -a
Linux yum 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13
17:56:26 UTC 2014 i686 athlon i686 GNU/Linux
- There are 4 commands that are relevant:
- The script is structured so that it should print nothing
unless the script branches to a success handler. After the
above-mentioned commands, there's a "d" command. The success
handler is below that.
- The first 3 above-mentioned components work properly
individually. Of particular relevance is that if I comment out
the white space remover, and also the curly brace handler, so
that the first command that runs is the JSON property verifier,
the "t" command works properly. Input that matches it causes
the "t" command to jump to the success handler, while input that
doesn't causes it to fall through to the "d" command, as
designed.
- If I run these 4 commands in sequence, the "t" command
always succeeds, even if the substitution right above it
fails. It's as if on the back end of the "t" command, sed
checks if any substitution in the whole script has
succeed on this line, and branches if any did. Since the white
space remover line "succeeds" pretty much all the time, this
would explain the symptom.
|