[BusyBox] Even more sed rumblings...

[Rob Landley]

[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/1pp"
sed: -e expression #1, char 9: multiple `p' options to `s' command
[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/0"
sed: -e expression #1, char 7: number option to `s' command may not be zero
[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/1p3"
sed: -e expression #1, char 9: multiple number options to `s' command
[landley at localhost busybox]$ echo "hello" | sed -e "1!!s/l/y/"
sed: -e expression #1, char 2: Extra characters after command
sed: -e expression #1, char 3: Multiple `!'s

It's the number of explicit error messages gnu sed has that impresses me...

Query: Gnu sed seems to eat anything up to a semicolon, closing curly bracket, 
or newline as an option to the s command:

[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/ s/fred/george/"
sed: -e expression #1, char 8: Unknown option to `s'
[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/;s/fred/george/"
heylo
[landley at localhost busybox]$ echo "hello" | sed -e "s/l/y/}s/fred/george/"
sed: -e expression #1, char 7: Unexpected `}'
[landley at localhost busybox]$ echo "hello" | sed -e "{s/l/y/}s/fred/george/"
sed: -e expression #1, char 9: Extra characters after command
[landley at localhost busybox]$ echo "hello" | sed -e "{s/l/y/};s/fred/george/"
heylo

Now the general theory of unix programming is to be permissive in what you 
accept and rigorous about what you emit.  From my reading of the spec, gnu's 
behavior about when to terminate search option parsing is about as valid as 
any because the spec just doesn't say.  What is the alternate behavior our 
#ifdef is trying to implement?  Is it a better reading of the spec, and is 
anybody out there actually ever likely to use it?

For one thing, when the gnu behavior is not being done, we only accept one 
option, and that ALSO violates the spec.  But as soon as you start accepting 
multiple options, you have to worry about where to stop...

Hmmm...

Rob