How the GNU coreutils are tested (2017)

http://www.pixelbeat.org/docs/coreutils-testing.html

by njn • 8 years ago

107 9 8 years ago

wmu• 8 years ago

Really nice overview.

ddevault• 8 years ago

Have you ever heard that old phrase "you can either make a program so simple it obviously has no bugs, or you can make a program so complex that it has no obvious bugs"?

GNU programs are the latter. That's why they need to go to such lengths to test "cat".

taeric• 8 years ago

Trite, and seems to ignore evolution. Most of the complexity in these utilities came from emergent behaviour.

Sir_Cmpwn2• 8 years ago

Wrong, most of the complexity was designed in. Have you ever read the source code for GNU coreutils? And maybe compared it to the POSIX specification for those tools?

drb91• 8 years ago

I don’t think this makes the observation any less true or valuable.

pixelbeat__• 8 years ago

Any practical program has the potential for bugs.

Note one can build the coreutils like busybox with the --enable-single-binary configure option. In this mode all 100 or so utils are combined to a single 1MB binary. I would not consider this bloated given the functionality provided.

Sir_Cmpwn2• 8 years ago

Busybox is no spring chicken, you know - it attempts to be coreutils and util-linux and ip(8) and dhcp(8) and vi and more all at once. Here are some numbers, all compiled with musl libc and stripped:

coreutils with --enable-single-binary=symlinks: 1.6M. Naturally this is a bit optimistic because coreutils is usually built with glibc.

busybox with `make defconfig`: 964K.

sbase[0] with `make sbase-box`: 340K.

[0] https://core.suckless.org/sbase

Even without considering that coreutils also ships with a heaping pile of support files for things like localization, it's still 5 times larger than sbase, and just under twice as big as busybox, which has 5-10x the functionality.

How the GNU coreutils are tested (2017)

Related Stories