On Mon, 1 Jul 2019 22:30:43 -0700
Michael Forney wrote:
Dear Michael,
> Thanks for investigating this, Laslo. Your findings seem to match my
> quick experimentation, and at this point I am leaning towards sticking
> with ARGBEGIN/ARGEND, but using a simpler implementation like the one
> I shared
On 2019-06-30, Laslo Hunhold wrote:
> What do the others think?
Thanks for investigating this, Laslo. Your findings seem to match my
quick experimentation, and at this point I am leaning towards sticking
with ARGBEGIN/ARGEND, but using a simpler implementation like the one
I shared or the one you
On Sun, 30 Jun 2019 21:20:43 -0700
Michael Forney wrote:
Dear Michael,
> I'm okay with switching to getopt(3), but also note that the current
> arg.h is probably more complicated than it needs to be. Here's a
> version I rewrote that I've been using in my own projects:
>
> https://git.sr.
On Sun, 30 Jun 2019 21:20:43 -0700
Michael Forney wrote:
Dear Michael,
> I'm okay with switching to getopt(3), but also note that the current
> arg.h is probably more complicated than it needs to be. Here's a
> version I rewrote that I've been using in my own projects:
>
> https://git.sr.
On 2019-06-30, Evan Gates wrote:
> On Fri, Jun 28, 2019 at 3:08 AM Michael Forney wrote:
>>
>> Then, maybe something like the following would work for those cases.
>>
>> ARGBEGIN {
>> default:
>> goto done;
>> } ARGEND
>> done:
>
> Seeing as we have more co
On Fri, Jun 28, 2019 at 3:08 AM Michael Forney wrote:
>
> Then, maybe something like the following would work for those cases.
>
> ARGBEGIN {
> default:
> goto done;
> } ARGEND
> done:
Seeing as we have more confusion and bugs to deal with in argument
handl
On 2019-06-28, Laslo Hunhold wrote:
>> Rather than add a special ENOFLAGS macro, I am tempted to revert
>> 9016d288 instead. The question that remains is how to handle arguments
>> that look like options (start with `-`) for tools that don't have any
>> specified options. It seems for some tools i
On 2019-06-28, Michael Forney wrote:
> As far as I know, unless the documentation states that a utility shall
> conform to the Utility Syntax Guidelines, it is not required to
> support `--`. However, it does use the language "should" which
> means[2]:
>
> For an implementation that conforms
On Fri, 28 Jun 2019 00:52:33 -0700
Michael Forney wrote:
Dear Michael,
> I'm really sorry for ignoring this for so long. Someone asked me about
> the `argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0;` one-liner,
> and I remembered this patch. I finally took the time to investigate
> this iss
Hi Mattias,
I'm really sorry for ignoring this for so long. Someone asked me about
the `argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0;` one-liner,
and I remembered this patch. I finally took the time to investigate
this issue in more detail.
On 2018-07-08, Mattias Andrée wrote:
> In POSIX-
In POSIX-2017 it was clarified via the documentation for
basename(1) and dirname(1) that all programs should support
-- unless specified otherwise.
Signed-off-by: Mattias Andrée
---
arg.h | 13 +
basename.c | 5 +
chroot.c | 2 +-
cksum.c| 8 +++-
dirname.c |
11 matches
Mail list logo
