Re: [BusyBox] Even more sed rumblings...

[Glenn McGrath]

On Sat, 27 Sep 2003 16:25:49 -0500
Rob Landley <address@hidden> wrote:

> 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?

(cc'ing to GNU sed bugs)


I think acording to the sed specs 's/foo/bar/ g' is two commands, in gnu
sed its one.

When i realised this i also realised that changing busybox sed to follow
the spec rather not GNU sed's behaviour would break a lot of scripts,
specifically ./configure scripts.

I put the compile time option in busybox, by default it follows what i
believe to be correct behaviour, but if you compile it with 'GNU sed
compatability' it will interpret the above example as one command. This
same compile time option can be used for other incompatabilities.


The spec is at
http://www.opengroup.org/onlinepubs/007904975/utilities/sed.html

The spec is dictating where spaces may be used, it states

The command has the format

[address[,address]]function

"The command can be preceded by <blank>s and/or semicolons. The function
can be preceded by <blank>s. These optional characters shall have no
effect."

i.e. ' 1,2s/foo/bar/' and '1,2 s/foo/bar/' are specifically allowed. 

"The r and w command verbs, and the w flag to the s command, take an
optional rfile (or wfile) parameter, separated from the command verb
letter or flag by one or more <blank>s; implementations may allow zero
separation as an extension."

's/foo/bar/wp' and 's/foo/bar/w p' are specifically allowed, the pattern
will appended to the file ./p

"Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
followed by a semicolon, optional <blank>s, and another command verb.
However, when the s command verb is used with the w flag, following it
with another command in this manner produces undefined results."

Here they are saying  '<command1> <command2>' is specifically allowed,
and they state that there is an ambuity due to the above example.

i.e. 's/foo/bar/w p' might be interpreted as 2 commands, 's/foo/bar/w'
and 'p'

The substitute function has the format

s/BRE/replacement/flags

The spec doesnt say the flag can preceded by <blank>s, if it did
it would be consistent for it to state that using flags can produce
undefined results.

The following commands would be ambiguous if <blank>'s were allowed
prior to the flag, i use ';' to seperate commands.

's/foo/bar/ p' is it 's/foo/bar/;p' or 's/foo/bar/p' 
's/foo/bar/ g' is it 's/foo/bar/;g' or 's/foo/bar/g'
's/foo/bar/ w p' is it 's/foo/bar/w p' or 's/foo/bar/w;p' or
s/foo/bar/;w p' 


As the spec details where <blank>'s are allowed to be used, and where
using <blank>s can cause ambiguity i think we should only allow <blank>s
where it says they are allowed, not allowing them where it doesnt say
they are forbiden.



Glenn