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@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
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
Re: [Toybox] [PENDING] [fold.c] [Question]
Hi,
On 08/27/18 03:09, haroon maqsood wrote:
> Hi Rob,
> I started working on fold.c cleanup,
> going through the code, and testing it out, i have a couple of questions.
>
> 1. gnu fold engulfs \n unconditionally i.e if there is a \n after the fold
> has
> happened that redundant \n does not make it to the output , that kind of
> makes sense but the posix spec only mentions carriage returns and only if
> the -b option is not specified. (Note* That the current pending/fold
> outputs
> an extra new line.)
If a line is exactly the length that a newline would need to go after the last
character, no additional newline should be added. If there is, that's a bug. If
you're referring to a different situation, please give an example.
> 2. the current fold implementation has unfold capability , that i think
> should
> not be squeezed in fold (as of yet), my plan is to have unfold as a
> separate
> utility that uses infrastructure from fold if necessary, or at least make
> unfold as a config option, please share your thoughts on this.
> 3. The tabstop thing is bit confusing for me, as the posix spec says "Tab
> stops
> shall be at each column position such that n modulo 8 equals 1." ( from
> this i understand that given the column the next column where the tab ends
> should be a column whose modulo 8 returns 1 , kind of this pseudo code ?
> where start is the current column. (am i understanding it right ?)
>
> int get_next_ts(int start)
> {
> if (start <= 1)
> return 9;
>
> if ((start % 8) == 1)
> return start;
>
> return get_next_ts(++start);
> }
Yes, this is correct. A more idiomatic algorithm would be:
int get_next_ts(int start)
{
return ((start + 8) & -8) + 1;
}
> Haroon
Samuel
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] Toybox test image / fuzzing
Your previous email definitely clarified how you want the test suite to work, thank you. I tried to answer your questions while avoiding duplication. I realize this thread is getting towards bikeshedding territory, so I've attempted to focus on the more factual/neutral/useful parts. On 03/14/2016 12:52 AM, Rob Landley wrote: On 03/13/2016 05:04 PM, Samuel Holland wrote: On 03/13/2016 03:32 PM, Rob Landley wrote: Because science is about reducing variables and isolating to test specific things? If you want to reduce variables, see the suggestion about unit testing. That said, what specifically was the suggestion about unit testing. "We should have some?" We should export a second C interface to something that isn't isn't a shell command for the purpose of telling us... what, exactly? I was referencing this: On 03/13/2016 01:06 PM, enh wrote: only having integration tests is why it's so hard to test toybox ps and why it's going to be hard to fuzz the code: we're missing the boundaries that let us test individual pieces. it's one of the major problems with the toybox design/coding style. sure, it's something all the existing competition in this space gets wrong too, but it's the most obvious argument for the creation of the _next_ generation tool... There is only so much variable-reduction you can do if you test the whole program at once. If you want to, as you suggested, "test specific things", like the command infrastructure, thoroughly, they have to be tested apart from the limits of the commands they are used in. On 03/13/2016 04:56 PM, Rob Landley wrote: If we need to test C functions in ways that aren't easily allowed by the users of those C functions, we can write a toys/example command that calls those C functions in the way we want to check. I think we actually agree with each other here. Considering how many times this pattern is already used, I don't see it adding much complexity. It's trading an ad hoc pattern used in ~17% of the tests for something more consistent and well-defined. Because 17% of the tests use it, 100% of the tests should get an extra argument? It's not adding any more features, just refactoring the existing behavior behind a common function instead of repeating it throughout the testsuite. For how to avoid adding complexity where it's not used, I'll have to defer to Andy's idea: On 03/13/2016 02:54 PM, Andy Chu wrote: Yes, that is exactly what I was getting at. Instead of "testing", there could be another function "testing-errors" or something. But it's not super important right now. I have seen a couple of tests that pass because they expect failure, but the command is failing for the wrong reason. Point them out please? I don't remember specifics at this point. I haven't looked at the test suite in much detail (other than reading the mailing list) since the end of 2014 or so when I was working on using it in a toy distro. http://thread.gmane.org/gmane.linux.toybox/1709 https://github.com/smaeul/escapist/commits/master If I remember correctly, one of them failed because it got a SIGSEGV, but to a shell that's just false. The other one was not crashing, but failing for another reason than expected. If I had to guess, one of them was cp, but that's because it's the one I spent the most time on. I'm positive they are both fixed now. you can go VERBOSE=fail make test_ls And have it not only stop at the first failure, but show you the diff between actual and expected, plus show you the command line it ran. (As a side note, the test harness I've written recently even gives you a diff of the expected and actual outputs when the test fails.) So does this one, VERBOSE=1 shows the diff for all of them, VERBOSE=fail stops after the first failure. It's not the DEFAULT output because it's chatty. Type "make help" and look at the "test" target. I think it's some of the web documentation too, and it's also in the big comment block at the start of scripts/runtest.sh. Okay, to some extent, I actually like way that better than mine. It gives you an overview of how close you are to conformance (you can count the failing tests, instead of quitting at the first failure), yet lets you drill down when desired. Like I said, I haven't studied the test infrastructure recently; I should go do that. Also, "the return code" implies none of the tests are pipelines, or multi-stage "do thing && examine thing" (which _already_ fails if do thing returned failure, and with the error_msg() stuff would have said why to stderr already). Yesterday I was poking at mv tests which have a lot of "mv one two && [ -e two ] && [ ! -e one ] && echo yes" sort of constructs. What is "the exit code" from that? Well, if we are testing mv, then the exit code is the exit code of mv. Not in the above test it isn't. "mv"
Re: [Toybox] Toybox test image / fuzzing
On 03/13/2016 01:18 PM, Rob Landley wrote: On 03/13/2016 03:34 AM, Andy Chu wrote: FWIW I think the test harness is missing a few concepts: - exit code blah; echo $? - stderr 2>&1 I think the idea here was the importance of differentiating between stdout and stderr, and between text output and return code. This is as simple as having a separate output variable for each type of output. Granted, it will usually be unambiguous as to the correctness of the program, but having the return code in the output string can be confusing to the human looking at the test case. Plus, why would you not want to verify the exit code for every test? It's a lot of duplication to write "echo $?" in all of the test cases. As for stdout/stderr, it helps make sure diagnostic messages are going to the right stream when not using the helper functions. -- Regards, Samuel Holland <sam...@sholland.org> ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Add support for 1024 as well as 1000 to human_readable.
decimal sizes. But you have to _use_ them in binary sizes. HN_IEC_PREFIXES isn't used at all. not even a test. Yeah, I have noticed for myself, following the standard and even making it the default so that you know what everything is in would be good, alas somewhat incompatable with custom, but are scripts using -h and then parsing it... something is likely that dumb. But it would be nice to actually do the right thing. Nothing extending the usage of the word "gibibytes" is the right thing. Then just do like util-linux and use "G" instead of "GiB" so until we find a place where we want to turn off HN_DECIMAL, we're good. (that's a harder thing to grep for, but i couldn't find an instance in FreeBSD.) I would hope not, I would regard it as a useless loss of presision. 9.9 will fit in the same space as 999 just fine. human_readable() _IS_ a useless loss of precision. That's what it's _for_. And the units advance by kilobytes so 9.9 and 999 are not rephrasings of each other. 999k and 1.0M can be from a rounding perspective, but "loss of precision" is the reason rounding _exists_... You can also set a flags to drop the space between number and prefix or use the ubuntu 0..1023 style also you can request the limited range 0..999, 1.0 k-999 k style in either SI or IEC Yes, but why would we want to? Strict conformance to the standard? avoiding the ->9.8Ki transition. The first I heard of this standard was when you mentioned it. Ubuntu clearly wasn't doing it. (If you git add a file, git diff shows no differences, mercurial diff shows it diffed against /dev/null. I'm STILL getting used to the weird little behavioral divergences.) git diff --cached That will show your staged changes (including added/removed file diffs). I hope this is interesting. It's very interesting and I'm keeping it around in case it's needed. I'm just trying to figure out if the extra flags are something any command is actually going to use. (And that's an Elliott question more than a me question, I never use -h and it's not in posix or LSB.) Odd, it has been in common useage for years, but I guess it was just whatever people felt a human would like to see rather than one of the standards. It's got a dozen flags because everybody who implemented this did it differently because the machine readable scriptable version is just to print out the actual NUMBER, thus the aesthetic cleanup is (or at least should be) just that. And because different quantities are measured with different units. Network speeds use decimal; memory sizes use binary; and disk sizes use both. Bringing an international standards body into a purely aesthetic decision is weird. ANSI vs ISO tea was a _joke_. (Ok, maybe the aesthetic output has mutated into functional due to screen scrapers, which is what Elliott was implying by scripts depending on -h output. In which case either rigorously copying the historical mistakes or breaking them really loudly is called for. Adding a standards body to that sort of mess gives me a headache long before we get into any sort of details.) Rob -- Regards, Samuel Holland <sam...@sholland.net> ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] Patches for basename, blkid, cat, and cp
Hello,
I've started working through the test suite trying to expand it and fix
where commands are failing. Here's what I've got so far for basename,
blkid, cat, and cp.
The cp test rewrite was done a few months ago, and looking at it now it
seems a bit dense. I was trying to minimize the number of temporary
files, but I may have overdone it. I can redo it if you wish. Note that
'cp -P' is still broken.
Also, I'm not sure how to add test cases for blkid with no arguments,
since it will depend on the local configuration.
--
Regards,
Samuel Holland sam...@sholland.net
From dc585eec2d57a7acf04ab89d170426696af5ce1b Mon Sep 17 00:00:00 2001
From: Samuel Holland sam...@sholland.net
Date: Wed, 11 Jun 2014 12:58:33 -0500
Subject: [PATCH 1/7] basename: fix segfault on null input; add tests
When passed an empty string, glibc's basename() returns a pointer to the
string . in its private memory. If an empty suffix is given, it fits
the condition of being shorter than the path, so we try to overwrite the
null byte and crash. We fix this by just ignoring empty suffixes; they
don't do anything anyway.
Also, updated the help text.
---
tests/basename.test | 7 ++-
toys/posix/basename.c | 6 +++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/tests/basename.test b/tests/basename.test
index 2f7a2ec..2789e29 100755
--- a/tests/basename.test
+++ b/tests/basename.test
@@ -4,6 +4,11 @@
#testing name command result infile stdin
+# Null Input
+testing basename null path basename '' .\n
+testing basename null path and suffix basename '' '' .\n
+testing basename path with null suffix basename a/b/c '' c\n
+
# Removal of extra /'s
testing basename /-only basename /// /\n
testing basename trailing / basename a// a\n
@@ -19,5 +24,5 @@ testing basename suffix=result basename .txt .txt .txt\n
testing basename reappearing suffix 1 basename a.txt.txt .txt a.txt\n
testing basename reappearing suffix 2 basename a.txt.old .txt a.txt.old\n
-# A suffix should be a real suffix, only a the end.
+# A suffix should be a real suffix, only at the end.
testing basename invalid suffix basename isthisasuffix? suffix isthisasuffix?\n
diff --git a/toys/posix/basename.c b/toys/posix/basename.c
index c49a5f3..917f62f 100644
--- a/toys/posix/basename.c
+++ b/toys/posix/basename.c
@@ -11,9 +11,9 @@ config BASENAME
bool basename
default y
help
-usage: basename string [suffix]
+usage: basename PATH [SUFFIX]
-Return non-directory portion of a pathname removing suffix
+Return non-directory portion of PATH, optionally removing SUFFIX.
*/
#include toys.h
@@ -23,7 +23,7 @@ void basename_main(void)
char *base = basename(*toys.optargs), *suffix = toys.optargs[1];
// chop off the suffix if provided
- if (suffix) {
+ if (suffix *suffix) {
char *s = base + strlen(base) - strlen(suffix);
if (s base !strcmp(s, suffix)) *s = 0;
}
--
2.2.1
From 3cd796c710b144e0900689e8c666e47ad620e3be Mon Sep 17 00:00:00 2001
From: Samuel Holland sam...@sholland.net
Date: Mon, 1 Dec 2014 11:56:05 -0600
Subject: [PATCH 3/7] tests/cat: Compare the correct file. /proc/self/exe means
different things to different processes.
---
tests/cat.test | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/cat.test b/tests/cat.test
index 3d5842a..1ca3dc1 100755
--- a/tests/cat.test
+++ b/tests/cat.test
@@ -17,7 +17,7 @@ testing cat file1 notfound file2 \
one\ntwo\ncat: notfound: No such file or directory\n
testing cat file1 \
-cat /proc/self/exe file1 cmp /proc/self/exe file1 echo yes \
+cat `which cmp` file1 cmp /proc/self/exe file1 echo yes \
yes\n
testing cat - file1 \
@@ -28,4 +28,4 @@ testing cat /dev/full \
cat - /dev/full 2stderr echo ok; cat stderr; rm stderr \
cat: xwrite: No space left on device\n zero\n
-rm file1 file2
\ No newline at end of file
+rm file1 file2
--
2.2.1
From 3824036e6fba66d6b9f1536cef883a067c60c6a9 Mon Sep 17 00:00:00 2001
From: Samuel Holland sam...@sholland.net
Date: Tue, 1 Jul 2014 22:48:53 -0500
Subject: [PATCH 4/7] cp: greatly expand test suite
---
tests/cp.test | 186 --
1 file changed, 102 insertions(+), 84 deletions(-)
mode change 100755 = 100644 tests/cp.test
diff --git a/tests/cp.test b/tests/cp.test
old mode 100755
new mode 100644
index 4327256..8eaf982
--- a/tests/cp.test
+++ b/tests/cp.test
@@ -3,99 +3,117 @@
[ -f testing.sh ] . testing.sh
# Create test file
-dd if=/dev/urandom of=random bs=64 count=1 2 /dev/null
+dd if=/dev/urandom of=rand1 bs=1 count=64 2 /dev/null
+dd if=/dev/urandom of=rand2 bs=1 count=64 2 /dev/null
+dd if=/dev/urandom of=rand3 bs=1 count=64 2 /dev/null
+ln -s rand1 symrand
-#testing name command result infile stdin
+mkdir four five six eight eleven
+mkdir -p nine/two/three/four
+touch zero
+touch nine/two/three/five
+touch nine/{six,seven,eight
Re: [Toybox] Working towards a release Sunday (July 6).
Hi,
On 07/01/2014 08:01 PM, Rob Landley wrote:
I meant to get out a release...
Well, before you do that, I have some patches and some questions. You
suggested a while back that someone should go through POSIX and add
tests for conformance (and tests in general), so I decided to do that.
I'm going through the spec in alphabetical order, and I haven't gotten
very far, but I thought I'd try to get this much sent in before you
release. I have attached patches for cleanup and tests of basename,
blkid, cat, and cp.
cp fails some of its tests that I did not try to fix (-P is broken);
some of the code in the for loop is too dense for me to figure out.
As always, your thoughts are appreciated, and so is the work you put
into toybox.
Rob
Regards,
Samuel
From 80b8b44829e50892f33560d7879e730a2fde8fe6 Mon Sep 17 00:00:00 2001
From: Samuel Holland sam...@sholland.net
Date: Wed, 11 Jun 2014 12:58:33 -0500
Subject: [PATCH 1/5] basename: fix segfault on null input; add tests
When passed an empty string, glibc's basename() returns a pointer to the
string . in its private memory. If an empty suffix is given, it fits
the condition of being shorter than the path, so we try to overwrite the
null byte and crash. We fix this by just ignoring empty suffixes; they
don't do anything anyway.
Also, updated the help text.
---
scripts/test/basename.test | 7 ++-
toys/posix/basename.c | 6 +++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/scripts/test/basename.test b/scripts/test/basename.test
index 2f7a2ec..2789e29 100755
--- a/scripts/test/basename.test
+++ b/scripts/test/basename.test
@@ -4,6 +4,11 @@
#testing name command result infile stdin
+# Null Input
+testing basename null path basename '' .\n
+testing basename null path and suffix basename '' '' .\n
+testing basename path with null suffix basename a/b/c '' c\n
+
# Removal of extra /'s
testing basename /-only basename /// /\n
testing basename trailing / basename a// a\n
@@ -19,5 +24,5 @@ testing basename suffix=result basename .txt .txt .txt\n
testing basename reappearing suffix 1 basename a.txt.txt .txt a.txt\n
testing basename reappearing suffix 2 basename a.txt.old .txt a.txt.old\n
-# A suffix should be a real suffix, only a the end.
+# A suffix should be a real suffix, only at the end.
testing basename invalid suffix basename isthisasuffix? suffix isthisasuffix?\n
diff --git a/toys/posix/basename.c b/toys/posix/basename.c
index c49a5f3..917f62f 100644
--- a/toys/posix/basename.c
+++ b/toys/posix/basename.c
@@ -11,9 +11,9 @@ config BASENAME
bool basename
default y
help
-usage: basename string [suffix]
+usage: basename PATH [SUFFIX]
-Return non-directory portion of a pathname removing suffix
+Return non-directory portion of PATH, optionally removing SUFFIX.
*/
#include toys.h
@@ -23,7 +23,7 @@ void basename_main(void)
char *base = basename(*toys.optargs), *suffix = toys.optargs[1];
// chop off the suffix if provided
- if (suffix) {
+ if (suffix *suffix) {
char *s = base + strlen(base) - strlen(suffix);
if (s base !strcmp(s, suffix)) *s = 0;
}
--
2.0.1
From 3a9f055a18f9098884a614a997b3909ad178569f Mon Sep 17 00:00:00 2001
From: Samuel Holland sam...@sholland.net
Date: Tue, 1 Jul 2014 20:21:46 -0500
Subject: [PATCH 2/5] cat: fix/add tests; minor cleanup
/proc/self/exe means two different things to cmp and cat
Add test coverage for -u argument
Tweak help text to be more in line with others
Turning the conditional into a while loop makes more sense to me
---
scripts/test/cat.test | 9 +++--
toys/posix/cat.c | 12 +---
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/scripts/test/cat.test b/scripts/test/cat.test
index 3d5842a..ec01595 100755
--- a/scripts/test/cat.test
+++ b/scripts/test/cat.test
@@ -9,6 +9,7 @@ echo two file2
testing cat cat echo yes oneyes\n one
testing cat - cat - echo yes oneyes\n one
testing cat file1 file2 cat file1 file2 one\ntwo\n
+testing cat -u file1 file2 cat -u file1 file2 one\ntwo\n
testing cat - file cat - file1 zero\none\n zero\n
testing cat file - cat file1 - one\nzero\n zero\n
@@ -16,8 +17,12 @@ testing cat file1 notfound file2 \
cat file1 notfound file2 2stderr echo ok ; cat stderr; rm stderr \
one\ntwo\ncat: notfound: No such file or directory\n
+testing cat -u file1 notfound file2 \
+cat -u file1 notfound file2 21 echo ok \
+one\ncat: notfound: No such file or directory\ntwo\n
+
testing cat file1 \
-cat /proc/self/exe file1 cmp /proc/self/exe file1 echo yes \
+cat `which cmp` file1 cmp /proc/self/exe file1 echo yes \
yes\n
testing cat - file1 \
@@ -28,4 +33,4 @@ testing cat /dev/full \
cat - /dev/full 2stderr echo ok; cat stderr; rm stderr \
cat: xwrite: No space left on device\n zero\n
-rm file1 file2
\ No newline at end of file
+rm
Re: [Toybox] [New toy] partprobe
On 05/25/2014 06:15 PM, Rob Landley wrote: Could you give me an example use case? (You resize the partitions without calling fdisk which would already call this ioctl...?) 1. You make changes to partitions with fdisk while they are in use (forgot to umount, vgchange -an, etc.), so after remedying the situation, you run partprobe to apply the already written changes. 2. You copy the partition table from another disk or restore from a backup using dd. Those are the times I've specifically used it. Another command that does the same thing is partx from util-linux. It gives you more control over adding/updating/removing individual partitions, though, so it's not entirely duplicate. Regards, Samuel Holland ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Fix od output format when using only legacy type specifiers
On 04/25/2014 05:55 AM, Rob Landley wrote: On 04/24/14 18:47, Samuel Holland wrote: This behavior broke building busybox with CONFIG_FEATURE_COMPRESS_USAGE as it uses od -v -b in applets/usage_compressed Busybox defconfig won't build with busybox's tr command (the libm probing fails), so I'm not _too_ embarassed about that. Still need to fix it, though. :) I'm assuming you're referring to building against uClibc. Bootstrapping busybox works fine against musl, but that's probably because it doesn't have a separate libm. - if (!TT.output_base) append_base(o2); + if (!TT.output_base !(toys.optflags + (FLAG_b|FLAG_c|FLAG_d|FLAG_o|FLAG_s|FLAG_x))) append_base(o2); Hmmm, that's a much more complicated test, and it's essentially repeating the flag list right above it. The TT.output_base check was _supposed_ to cover this. The intended logic was only add an output type if we haven't already got an output type, but output_base is the explicit list of command line output types so it's checking the wrong variable. TT.types is the count of output types (incremented by append_base) so checking that's not zero is the correct thing to do. Checked in the smaller fix. Works for me. Thanks, Rob Thanks, Samuel ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] [PATCH] Fix od output format when using only legacy type specifiers
Toybox had been adding the default oS output format unless an explicit -t option had been given, even if one of the legacy shortcut options was given. This behavior broke building busybox with CONFIG_FEATURE_COMPRESS_USAGE as it uses od -v -b in applets/usage_compressed --- toys/posix/od.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/toys/posix/od.c b/toys/posix/od.c index 6c7cc94..10fcc39 100644 --- a/toys/posix/od.c +++ b/toys/posix/od.c @@ -278,7 +278,8 @@ void od_main(void) if (toys.optflags FLAG_o) append_base(o2); if (toys.optflags FLAG_s) append_base(d2); if (toys.optflags FLAG_x) append_base(x2); - if (!TT.output_base) append_base(o2); + if (!TT.output_base !(toys.optflags + (FLAG_b|FLAG_c|FLAG_d|FLAG_o|FLAG_s|FLAG_x))) append_base(o2); loopfiles(toys.optargs, do_od); ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Fold bug fixes; unfold implementation
On 04/20/2014 09:47 PM, Rob Landley wrote: On 04/04/14 01:59, Samuel Holland wrote: This version of fold fixes major bugs (infinite loop, overflow) and adds an option for un/refolding text. Poking at cleanup, and I was wondering if you could suggest some good tests for this? diff -u (./toybox fold -w10 README | ./toybox fold -u ) (./toybox fold -w20 README | ./toybox fold -u) Those should be the same. Interestingly enough, that provides different output every time I run it. There must be some sort of buffer-end behavior based on how much it reads at a time. Besides just comparing with the GNU implementation, other test cases would mostly involve control characters and making sure it inserts breaks appropriately (using wc -l). $ echo -e '123456789012345678901' | ./toybox fold -w20 12345678901234567890 1 $ echo -e '12345678901234567890\b1' | ./toybox fold -w20 12345678901234567891 $ echo -e '12345678901234567890\b1' | ./toybox fold -bw20 12345678901234567890 1 $ echo -e '12345678901234567890\r1' | ./toybox fold -w20 12345678901234567890 1 (This one is broken for some reason) $ echo -e '1234567890123456\t3' | ./toybox fold -w20 1234567890123456 3 $ echo -e '1234567890123456\t\b3' | ./toybox fold -w20 1234567890123456 3 $ echo -e '1234567890123456\t\b\b\b\b\b\b\b7' | ./toybox fold -w20 1234567890123456 7 $ echo -e '1234567890123456\t\b\b\b\b\b78' | ./toybox fold -w20 1234567890123456 7 8 $ echo -e '1234567890123456\t\b\b\b\b\b78' | ./toybox fold -sw20 1234567890123456 78 (I hope those aren't too mangled) I built fold with scripts/single.sh and then did: diff -u (fold -w 60 README) (./fold -w 60 README) And it just had an extra newline on the end, which is probably within tolerances? (I'm rereading the spec, it's been a while...) The problem is that I'm unconditionally putc'ing a newline at the end of the file. Assuming the file already ends with a newline, I shouldn't ever have to to that. That fixes both that case and the fold-unfold adding two lines. But that was the current version, and all the changes I've made to it so far were whitespace and curly brackets and shuffling variable declarations around and such. I admit I tend to turn switch/case statements into if/else staircases because the end result almost always winds up smaller code both in source and in binary. (Needing both the label and the break lines is a strike against switch/case, and nobody can ever quite agree on how to indent case statements either. It can come out ahead if you make a lot of use of fallthrough, either having multiple labels for the same funcitonality or just doing the clever fallthrough thing ala tab and space in your code. But it usually doesn't.) I'm fine with that, as long as we maintain the don't-break-after-this-character semantics. But with a change that intrusive, I really want to test the result well, so... It looks like I need to do more testing in general... I apologize for giving you broken code. I was just excited it worked for my (simple) use case. Rob Samuel P.S. you currently have toys/pending/iconv.c as default yes ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] [PATCH] Fold bug fixes; unfold implementation
This version of fold fixes major bugs (infinite loop, overflow) and adds an option for un/refolding text. fold-unfold-bugfix.patch Description: Binary data Regards, Samuel Holland sam...@sholland.net___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] fold implementation
On Apr 3, 2014, at 5:56 PM, Rob Landley r...@landley.net wrote: The -u option to fold isn't currently being used... Could you describe a little more how unfold would work? Generally, I write papers and such in a text editor with hard wrapping, like nano, and then transfer them to LibreOffice for formatting. So I go from newline after X columns and a blank line between paragraphs to long lines with a single newline between paragraphs. The simplest algorithm would be to remove all newlines except double newlines (and convert those to single). If -s was specified, we would only remove newlines after spaces and tabs (or unless there was no space in that line). Finally, if -w was specified, we would re-wrap at that width. Rob Regards, Samuel Holland sam...@sholland.net ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] [toybox] fold implementation
Hello, everyone. Here is a basic implementation of fold[0]. It does not support multibyte characters, though that would probably just require more switch cases. This is my first contribution, so please comment your thoughts/what I can improve. I was planning to write an unfold utility that basically did the opposite. Although I don't think it's in any standard, would it still be of any interest? [0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fold.html fold.patch Description: Binary data Regards, Samuel Holland sam...@sholland.net___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
