GNU bug report logs - #8103
tac RFE: accept -z, --zero-terminated option

Previous Next

Full log

Message #20 received at 8103 <at> debbugs.gnu.org (full text, mbox):

From: Bjartur Thorlacius <svartman95 <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 8103 <at> debbugs.gnu.org
Subject: Re: bug#8103: NUL terminated lines
Date: Fri, 25 Feb 2011 17:35:08 +0000

On 2/24/11, Jim Meyering <jim <at> meyering.net> wrote:
> Bjartur Thorlacius wrote:
>> On 2/24/11, Jim Meyering <jim <at> meyering.net> 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 .

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.