Re: [hackers] [PATCH][sbase] paste: Allow null delim

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Thu, 5 Mar 2020 11:16:10 +0100

On Thu, 5 Mar 2020 01:42:37 -0800
Michael Forney <mforney_AT_mforney.org> wrote:

> On 2020-03-05, Quentin Rameau <quinq_AT_fifth.space> wrote:
> >> Looking at POSIX, I see that `-d '\0'` must be supported, `-d ""`
> >> is unspecified
> >
> > I don't think so, -d "" is just a list with an empty string.
> > So -d '\0' is equivalent to -d '', '\0' is here to let the user
> > express an empty string in a list, which wouldn't be possible
> > otherwise (like how would one specify empty string in a list like
> > 'ab<empty-string>cd').
>
> Here is a direct quote from POSIX:
>
> The commands:
>
> paste -d "\0" ...
> paste -d "" ...
>
> are not necessarily equivalent; the latter is not specified by
> this volume of POSIX.1-2017 and may result in an error.

My bad, I didn't read that far.

But,

> >> and `-d""` is invalid, since paste(1) must follow the
> >> utility syntax guidelines (guideline 7).
> >
> > Not sure what you mean there, -d"" is the concatenation of -d and
> > '', which is standard.
> > Did you quote the correct guideline? “Guideline 7: Option-arguments
> > should not be optional.” here there's an option-argument, that's an
> > empty string.
>
> I guess it's a combination of 6 and 7. Option arguments must be
> separate parameters and non-optional (unless specified otherwise).
> There is an exception made that allows conforming implementations to
> accept an option adjacent with its option argument in the same
> argument, but I think this only makes sense if the option-argument is
> non-empty.
>
> POSIX says
>
> The construct '\0' is used to mean "no separator" because historical
> versions of paste did not follow the syntax guidelines, and the
> command:
>
> paste -d"" ...
>
> could not be handled properly by getopt().
>
> I think this implies that `paste -d""` is no longer valid, due to the
> requirements of the syntax guidelines.

Rather it's due to a getopt() limitation with the (not so) special case
of an empty string option-argument, but I'm not sure why.

The utility guidelines permits concatenating options and
option-arguments, while it's true that the prefered syntax is to
separate them.

12.1, 2.a:
“If the SYNOPSIS of a standard utility shows an option with a mandatory
option-argument (as with [ -c option_argument] in the example), a
conforming application shall use separate arguments for that option and
its option-argument. However, a conforming implementation shall also
permit applications to specify the option and option-argument in the
same argument string without intervening <blank> characters.”

Without commenting on the patch itself, I think it's fine to allow '\0'
and '', especially as we don't use getopt(), partly due to it being
broken in most implementations (and having such limitations?), and the
standards says it's unspecified, not undefinied.
Received on Thu Mar 05 2020 - 11:16:10 CET