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

[haroon maqsood]

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.

Thanks
Haroon

________________________________
From: Samuel Holland <samuel at sholland.org>
Sent: Wednesday, August 29, 2018 11:49 PM
To: haroon maqsood; toybox at lists.landley.net
Subject: Re: [Toybox] [PENDING] [fold.c] [Question]

On 08/29/18 17:28, haroon maqsood wrote:
> PFA a patch for unit tests i added that can maybe go in when fold moves from
> pending??, the main intention is to discuss what i was unable to
> communicate(limitation on my part), i added a comment too so if anyone can
> cross check , that would be helpful

Thanks for providing concrete examples.

Test 1: Per the spec, the tab character goes up to the next tab stop. Since the
next character is at column 9 (the next tab stop), the tab made the line 8
characters long, which is too wide. Since the tab makes the line too wide, you
must put a newline before it.

Test 2: "ef d" is exactly 4 characters, so there's no need to split the line.
Regardless of if you split after whitespace or in the middle of a word, the
column count resets when you output a newline.

Test 3 and 4 look okay.

Test 5: This is the tough one, because it's outside of the spec. The input
doesn't end in a newline, so it's technically not a text file. fold(1) is only
specified to operate on text files. Personally, I'd say add the newline, to make
the output a text file. Apparently GNU disagrees.

Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20180830/5a202bdc/attachment-0001.html>