[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rob Landley
Subject: Re: [BusyBox] Even more sed rumblings...
Date: Sat, 27 Sep 2003 20:06:27 -0500
User-agent: KMail/1.5

On Saturday 27 September 2003 19:37, Glenn McGrath wrote:
> 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.

I think that according to the spec it's one command.

> "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.

No, they are saying that '<command1>; <command2>' is allowed.  The semicolon 
is not optional here.  (GNU sed has been implementing this behavior for ten 
years without major complaints.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]