Re: [List] Re: Nice easy sed question

Kyle Evans wrote:
> Bob Proulx wrote:
> > I think the synopsis is about as good as it can get in the document
> > format of a manpage.  It is missing a little explanation that says how
> > to terminate a, i, c commands and how to chain in multiple commands
> > with one following the other.  It wasn't designed to squeeze an entire
> > sed program all on one line, at least not all of the time.  There are
> > some quite long and pretty gnarly multiline sed programs that are
> > unreadable on multiple lines without jamming them all together onto
> > one line.
>
> The SYNOPSIS is factually incorrect, though (see https://reviews.freebsd.org/D52495).

Oh!  I thought we were talking about this part.

     [1addr]a\
     text    Write text to standard output immediately before each attempt to
             read a line of input, whether by executing the “N” function or by
             beginning a new cycle.
     [2addr]c\
     text    Delete the pattern space.  With 0 or 1 address or at the end of a
             2-address range, text is written to the standard output.
     [1addr]i\
     text    Write text to the standard output.

That's the documentation I thought I was referring to.  It's not
really clear that a newline terminates the command.  An example or
three would help to make that more apparent.

> We don't do GNU-style permutation of non-option arguments and, as far as I'm aware,

And I would not have thought to try it with placing options in any
other order either.

> have never done so in getopt(3)[0].  Stating that any options can come after the
> script/command will just lead to unexpected behavior, because we treat those as
> files rather than restarting option parsing.

     sed [-Ealnru] command [-I extension] [-i extension] [file ...]

Right.  That's wrong.  At least something like this.

     sed [-Ealnru] [-I extension] [-i extension] command [file ...]

Or whatever you wrote in the bug report that is being reviewed.

Bob

P.S. I have this belief that option permutation is a style that came
to GNU from MS-DOS which always uses /options at the end of the option
arguments rather than before them.

    dir *.* /p

I think a generation of people grew up with that syntax that options
go at the end which caused them to want to type it in that way with
Unix commands too.  I am sure it was at least an influence anyway.