On 2/22/19 8:50 PM, Bernhard Voelker wrote:
> So the latest patch set [*] is good to push?
Padraig pushed the gnulib change at:
https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=e3970fb989
and sync'd coreutils to that commit.
I pushed the CU change on top at:
https://git.sv.gnu.org/cgit/coreuti
On 2/22/19 4:06 PM, Eric Blake wrote:
> Bad idea, for the reasons given above. Leave it as-is, with the change
> in yes behavior being an intentional bug fix.
Good point(s).
So the latest patch set [*] is good to push?
If yes: I don't have push perms on gnulib, so if someone of you would
be so ki
On 2/22/19 1:46 AM, Bernhard Voelker wrote:
>> Finally, I documented the change in 'yes' in NEWS regarding:
>>
>> $ yes a -- b | head -n1
>> a -- b
>> vs.
>> $ src/yes a -- b | head -n1
>> a b
>
> What about putting 'yes' into the 'nohup' category? I mean, we have
> the SCAN_ALL flag in
On 2/21/19 9:15 AM, Bernhard Voelker wrote:
> On 2/19/19 2:53 PM, Eric Blake wrote:
>> [...] - just blindly set
>> opterr without worrying about restoring it.
>
> You are both right, sorry for the confusion.
> Adjusted patches attached.
>
> I added some more test cases as well.
> Finally, I docum
On 2/19/19 2:53 PM, Eric Blake wrote:
> [...] - just blindly set
> opterr without worrying about restoring it.
You are both right, sorry for the confusion.
Adjusted patches attached.
I added some more test cases as well.
Finally, I documented the change in 'yes' in NEWS regarding:
$ yes a -- b
On 2/19/19 2:24 AM, Bernhard Voelker wrote:
> On 2/18/19 11:20 AM, Assaf Gordon wrote:
>> [...] what do you think ?
>
> Thanks for driving this.
>
> To Eric's suggestion, I'd remove the RESET_OPTIND function argument,
> because it's never used.
> Re. OPTIND: what about resetting the values of all
Hello,
On 2019-02-19 1:24 a.m., Bernhard Voelker wrote:
On 2/18/19 11:20 AM, Assaf Gordon wrote:
[...] what do you think ?
To Eric's suggestion, I'd remove the RESET_OPTIND function argument,
because it's never used.
+1
Re. OPTIND: what about resetting the values of all involved externals
On 2/18/19 11:20 AM, Assaf Gordon wrote:
> [...] what do you think ?
Thanks for driving this.
To Eric's suggestion, I'd remove the RESET_OPTIND function argument,
because it's never used.
Re. OPTIND: what about resetting the values of all involved externals
to their previous value?
+ int saved_
Hello,
On 2019-02-15 1:19 p.m., Eric Blake wrote:
On 2/15/19 12:32 PM, Assaf Gordon wrote:
There is at least one change in behavior, not sure if this is
bad enough to be a regression or doesn't really matter:
$ yes-OLD me -- --help | head -n1
me -- --help
$ yes-NEW me -- --help | hea
On 15/02/19 10:32, Assaf Gordon wrote:
> Hello Eric and all,
>
>
> Thanks for the quick and detailed review.
> I've amended all the issues you mentioned.
>
> On 2019-02-13 8:20 p.m., Eric Blake wrote:
>>> 15 files changed, 46 insertions(+), 141 deletions(-)
>>
>> Nice diffstat.
>
> These are
On 2/15/19 12:32 PM, Assaf Gordon wrote:
> Attached updated patches, with tests.
It's easier to review patches when they are attached inline without
compression (then I don't have to decompress and copy from my editor
back into my email), but I can cope with your .gz attachments.
>
> comments w
Hello Eric and all,
Thanks for the quick and detailed review.
I've amended all the issues you mentioned.
On 2019-02-13 8:20 p.m., Eric Blake wrote:
15 files changed, 46 insertions(+), 141 deletions(-)
Nice diffstat.
These are of course Bernhard's improvements,
I just did the testing (and
On 2/13/19 6:56 PM, Assaf Gordon wrote:
> Hello,
>
> On 2019-02-12 7:00 p.m., Eric Blake wrote:
>> On 2/12/19 7:21 PM, Assaf Gordon wrote:
>>
>>> + optind = 1;
>>
>> Why are you doing this in every caller, instead of doing it just once
>> inside the body of parse_gnu_standard_options_only(), so t
Hello,
On 2019-02-12 7:00 p.m., Eric Blake wrote:
On 2/12/19 7:21 PM, Assaf Gordon wrote:
+ optind = 1;
Why are you doing this in every caller, instead of doing it just once
inside the body of parse_gnu_standard_options_only(), so that the state
is left unchanged at optind==1 if there were
On 2/12/19 7:21 PM, Assaf Gordon wrote:
> Eric's suggestion was not wrong, "optint=0"
> was already used (and worked just fine) in parse_long_option.
>
> But there's a catch: after calling "parse_long_options"
> (which sets optind=0), every program called "getopt_long"
> again! and that call set
Hello,
A follow-up and more details:
On 2019-01-12 11:30 a.m., Assaf Gordon wrote:
On 2019-01-12 8:42 a.m., Eric Blake wrote:
On 1/11/19 6:23 PM, Assaf Gordon wrote:
- optind = 0;
+ optind = 1;
Ouch. You're hitting the portability problem of the difference between
BSD and glibc.
I only
Hello Eric,
On 2019-01-12 8:42 a.m., Eric Blake wrote:
On 1/11/19 6:23 PM, Assaf Gordon wrote:
- optind = 0;
+ optind = 1;
Ouch. You're hitting the portability problem of the difference between
BSD and glibc.
Otherwise many things fail like so:
$ ./src/dd
./src/dd: unrecognized o
On 1/11/19 6:23 PM, Assaf Gordon wrote:
> For the gnulib patch, I believe the following is needed:
>
> diff --git a/lib/long-options.c b/lib/long-options.c
> index 52ef1f2f8..9567d5135 100644
> --- a/lib/long-options.c
> +++ b/lib/long-options.c
> @@ -139,7 +139,7 @@ parse_gnu_standard_option
Hello Berny and all,
On 2018-11-29 1:48 a.m., Bernhard Voelker wrote:
The attached are quite raw attempts to address this - yes, as a function
instead of a macro. ;-)
* [PATCH] long-options: add parse_gnu_standard_options_only
gnulib patch!
For the gnulib patch, I believe the following is
On 11/27/18 10:04 PM, Paul Eggert wrote:
> I'd rather see a function than a big macro like that. Can we do it as a
> function instead?
>
> Is the idea to deprecate and/or stop using parse_long_options, since it
> doesn't work the way the Gnu Coding Standards says it should? If so,
> maybe it wo
I'd rather see a function than a big macro like that. Can we do it as a
function instead?
Is the idea to deprecate and/or stop using parse_long_options, since it
doesn't work the way the Gnu Coding Standards says it should? If so,
maybe it would be simpler to change parse_long_options instead.
On 11/26/18 2:24 AM, Bernhard Voelker wrote:
E.g. for 'yes', all of the following successfully detecting
the --version option (and likewise for --help):
$ src/yes --version
$ src/yes hello --version
$ src/yes hello --version world
$ src/yes --version hello
$ src/yes h
On 11/24/18 7:45 PM, Paul Eggert wrote:
> Why is the situation different for 'yes' than for other commands? The GNU
> coding
> standards are clear that 'yes --help foo' should act like 'yes --help'.
>
> https://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html
Thanks for the link. Indee
Bernhard Voelker wrote:
At least for 'yes', one could argument that the program should only
care about the (GNU) long options --help and --version if they are the
only argument, and take everything else as the string(s) to be output
Why is the situation different for 'yes' than for other comman
On 11/24/18 1:52 AM, Pádraig Brady wrote:
> On 22/11/18 10:09, Uko Kokņevičs wrote:
>> So I was messing around with `yes`, and after running `yes --help me` it
>> output this:
>>
>>> yes: unrecognized option '--help'
>>> Try 'yes --help' for more information.
>>
>> After a bit of more testing of
On 22/11/18 10:09, Uko Kokņevičs wrote:
> So I was messing around with `yes`, and after running `yes --help me` it
> output this:
>
>> yes: unrecognized option '--help'
>> Try 'yes --help' for more information.
>
> After a bit of more testing of this, I found the same reaction from
> `whoami`. I
So I was messing around with `yes`, and after running `yes --help me` it
output this:
> yes: unrecognized option '--help'
> Try 'yes --help' for more information.
After a bit of more testing of this, I found the same reaction from
`whoami`. I believe this might be because both `yes` and `whoami`
27 matches
Mail list logo
