It's testing for bloat. It drives home the fact that we will not compromise on making good, simple tools. If we did our tests would fail us.
Our true(1) and false(1) implementations are POSIX without extensions and shouldn't be extended. Maybe it would be better to only have them in the POSIX compatibility section.
Integer parsing has to be done in our C programs in a couple of places:
- src/dj.c:299 has an awkward integer parsing…
Goodness, I just saw the WIP: . It makes sense then that it seemed that this was unfinished. I really like where this is headed though.
GNU false(1), a notoriously POSIX non-compliant implementation, would pass here, as (if I recall) it returns EXIT_FAILURE for improper usage. It shouldn't pass, though, because it prints a usage text to the standard output when usage help or version information are queried.
This seems ineligant. Programmatically print the test suite name at tests/$suite/Name, falling back to the folder name itself.
This should go before the previous for loop as it will crash faster on incorrect invocation.
Could we use [ as test? The left-bracket use is a code smell for me as it tends to be more error prone. This particular usage seems fine.
I added some small additional fixes to this branch.
- You changed
return 0toreturn EXIT_SUCCESS, which was good, butreturn 1was still present, so I changed it toreturn EXIT_FAILURE.…