On Mon, Jun 29, 2015 at 7:19 PM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> Darn it. I see that I mistakenly pushed one of your patches
>> when I pushed the linkat.m4 fix, Paul. Sorry about that.
>> Happy to revert, if you'd like that. Let me know.
>
> No problem. I installed the attached fur
Jim Meyering wrote:
Darn it. I see that I mistakenly pushed one of your patches
when I pushed the linkat.m4 fix, Paul. Sorry about that.
Happy to revert, if you'd like that. Let me know.
No problem. I installed the attached further patch; does it fix things for you?
If we can't get this to w
On Mon, Jun 29, 2015 at 2:01 PM, Jim Meyering wrote:
> On Mon, Jun 29, 2015 at 11:39 AM, Paul Eggert wrote:
>> Jim Meyering wrote:
>>>
>>> the first variant compiled
>>> just fine here (and probably everywhere),
>>> so HAVE_GETGROUPLIST_WITH_INT was not defined.
>>
>>
>> Yes, well, it did work on
On Mon, Jun 29, 2015 at 11:39 AM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> the first variant compiled
>> just fine here (and probably everywhere),
>> so HAVE_GETGROUPLIST_WITH_INT was not defined.
>
>
> Yes, well, it did work on GNU/Linux, which is what I tested it on.
>
> How about if w
Jim Meyering wrote:
the first variant compiled
just fine here (and probably everywhere),
so HAVE_GETGROUPLIST_WITH_INT was not defined.
Yes, well, it did work on GNU/Linux, which is what I tested it on.
How about if we make the check pickier, so that it is likely to be triggered
even with
On Sun, Jun 28, 2015 at 11:48 PM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> I compiled the just-published snapshot on OS X configured with
>> --enable-gcc-warnings, and saw this:
>>
>> lib/mgetgroups.c: In function 'mgetgroups':
>> lib/mgetgroups.c:90:45: error: pointer targets in passing arg
2015-06-29 17:25:11 +0100, Pádraig Brady:
[...]
> > $ printf '%s\n' a:b c d:e | paste -d: - /dev/null | cut -d: -f2
> > b
> >
> > e
>
> Good point. Or to better support field ranges:
>
> $ printf '%s\n' a:b c d:e | sed 's/^[^:]*$/&:/' | cut -d: -f2-
> b
>
> e
[...]
Maybe better as:
$ printf '
On 29/06/15 16:54, Stephane Chazelas wrote:
> 2015-06-29 16:31:00 +0100, Pádraig Brady:
> [...]
>>> When there is only one column and we go beyond 1 with the -f option, the
>>> output remains the first column
>>>
>>> $ echo "test1" | cut -d' ' -f1
>>> test1
>>> $ echo "test1" | cut -d' ' -f2
>>> t
2015-06-29 16:31:00 +0100, Pádraig Brady:
[...]
> > When there is only one column and we go beyond 1 with the -f option, the
> > output remains the first column
> >
> > $ echo "test1" | cut -d' ' -f1
> > test1
> > $ echo "test1" | cut -d' ' -f2
> > test1
> > $ echo "test1" | cut -d' ' -f3
> > tes
Hi Pádraig,
Oh, I see - thanks for letting me know.
Kind regards,
Tomek
> On 29 Jun 2015, at 16:31, Pádraig Brady wrote:
>
> tag 20928 notabug
> close 20928
> stop
>
> On 29/06/15 09:18, Kuchta, Tomasz wrote:
>> Hello.
>>
>> I’m not sure if this is a bug - I just wanted to let you know.
>> T
tag 20928 notabug
close 20928
stop
On 29/06/15 09:18, Kuchta, Tomasz wrote:
> Hello.
>
> I’m not sure if this is a bug - I just wanted to let you know.
> Thanks,
> Tomek
>
> ——
>
> When there is more than one column and we go beyond the number of columns
> with the -f option, the output is emp
Hello.
I’m not sure if this is a bug - I just wanted to let you know.
Thanks,
Tomek
——
When there is more than one column and we go beyond the number of columns with
the -f option, the output is empty
$ echo "test1 test2" | cut -d' ' -f1
test1
$ echo "test1 test2" | cut -d' ' -f2
test2
$ echo
12 matches
Mail list logo
