[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8103: NUL terminated lines
From: |
Bjartur Thorlacius |
Subject: |
bug#8103: NUL terminated lines |
Date: |
Fri, 25 Feb 2011 17:35:08 +0000 |
On 2/24/11, Jim Meyering <address@hidden> wrote:
> Bjartur Thorlacius wrote:
>> On 2/24/11, Jim Meyering <address@hidden> wrote:
>>> Bjartur Thorlacius wrote:
>>>>> Maybe we should modify tac to add the -z option. Would you care to
>>>> write a patch?
>>>> It would be redundant, as tac -s $'\0' is equivalent.
>>>
>>> Are you using a non-GNU version of tac?
>> I don't remember whether I was using FreeBSD or GNU tac.
>
> Please confirm. I may make a difference.
>
I was using GNU tac, but didn't actually test tac -s $'\0'.
It parses it as a C string. Makes sense, once you've written it.
>>> If so, please tell us which one -- that may influence
>>> the decision of whether to make "-s ''" work or to add -z.
>>>
>>> With GNU tac, that has never worked:
>>>
>>> $ tac -s ''
>>> tac: separator cannot be empty
>>>
>> NUL!=the empty string.
>
> tac treats them the same way.
>
>>> Making -s accommodate an empty string argument is a possibility,
>>> but that change looks like it'd be relatively disruptive.
>>>
>> I don't understand what that would do. Self-delimited strings would be
>> quite disruptive, indeed, but I gather that's not what you're talking
>> about.
>
> Changing tac.c to make -s accommodate an empty string
> looks like it would require changes that are too invasive.
>
Maybe, but there's nothing stopping us from using non-standard string
functions .