[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: |
Sun, 28 Sep 2003 04:10:22 -0500 |
User-agent: |
KMail/1.5 |
On Saturday 27 September 2003 20:55, Glenn McGrath wrote:
> On Sat, 27 Sep 2003 20:06:27 -0500
>
> Rob Landley <address@hidden> wrote:
> > On Saturday 27 September 2003 19:37, Glenn McGrath wrote:
> > > "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.)
>
> hmm, i was interpreting it as "can be followed by a semicolon _or_
> optional <blank>s, and another command verb", i see it now.
>
> So the w flag is only troublesome if the filename starts with a
> semicolon.
>
> So waht the spec is saying is that if the command + arguments can have
> spaces in it ie. the comamnds '{','a', 'b', 'c', 'i','r', 't', 'w',
> ':', and '#' then to seperate the command from any following commands
> you must use a semicolon followed by optional <blank>s
>
> In that case GNU sed isnt following the spec because it doesnt require
> the semicolon ;)
>
> ': loo p'
Possibly, but in that case it isn't ambiguous, since labels can't have blanks
in them and b can only have one label. So we know when we're done, and the
next skip is semicolon-whitespace. s can have more than one option, so
whitespace isn't a sufficient separator...
Accepting non-conforming input isn't really a violation of the spec, it's an
extension of the spec. Failing to accept conforming input is the only real
violation (unless it specifies what you must do in case of a violation, which
it doesn't here...)
> Glenn
Rob