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 <sam...@sholland.org> Sent: Wednesday, August 29, 2018 11:49 PM To: haroon maqsood; toybox@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
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net