[Toybox] [PENDING] [fold.c] [Question]

[enh]

what he means is that if you read POSIX (
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fold.html) they
only specify the behavior for _text_ files, and thus behavior on non-text
files is undefined, and any behavior would be acceptable as far as POSIX is
concerned. (though, as you say, some choices make more sense than others.
rebooting would be POSIX compliant but very unhelpful.)

On Wed, Aug 29, 2018 at 5:55 PM haroon maqsood <maqsood3525 at live.com> wrote:

> Hi,
> fold -b -w10 generated/unstripped/toybox
> fold -w10  generated/unstripped/toybox
>
> fold  does operate on non text files, you can pipe it to less and see the
> quick difference, i know no one would use fold in this way
> but still, lets focus on fixing the bugs 😊
> Thanks
> Haroon
>
> ------------------------------
> *From:* Samuel Holland <samuel at sholland.org>
> *Sent:* Thursday, August 30, 2018 12:28 AM
> *To:* haroon maqsood; toybox at lists.landley.net
> *Subject:* Re: [Toybox] [PENDING] [fold.c] [Question]
>
> On 08/29/18 19:11, haroon maqsood wrote:
> > Test 1: Agreed (thanks for pointing out i missed it) i'll remove it.
> > Test 2: IMO as adding d breaks the spec by not outputting the new line
> after
> > space, gnu is wrong here.
> > Test 3: then why not stat the files or check by any other way that they
> are only
> > regular files? IMO this should be a normal case that it makes width
> match so
> > new line is due.
>
> It *is* a regular file, but it's not a *text* file. Being a text file
> depends on
> the contents of the file, such as it can't contain NUL characters and must
> end
> with a newline character.
>
> Samuel
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20180829/2751a209/attachment-0001.htm>