GNU coreutils can be built as a single binary with ./configure --enable-single-binary. One can install this variant on Fedora for example with the coreutils-single package, and this is used in some container images.
It's also worth mentioning a recent improvement we made (in coreutils 8.28) to the operation of the `tail | grep` example in the article. tail now notices if the pipe goes away, so one could wait for something to appear in a log, like:
tail -f /log/file | grep -q match
then_do_something
The vi vs emacs thing permeates a lot of tools.
I find it useful to map all tools to be consistent with one or the other.
Personally I use vi. Unfortunately setting vi mode for readline has a few caveats, but I was able to work around all of them with the settings in:
One might be wondering why 'test' and '[' are separate binaries at all.
This is to give maximum flexibility wrt copying binaries etc.
Note one can build coreutils like busybox as a single binary,
by just `./configure --enable-single-binary` at build time.
This is already available as an option on Fedora at least through
the coreutils-single (1.2MB) package.
yes(1) is the standard unix way of generating repeated data.
It's good to do this as quickly as possible.
I really don't understand why so many get annoyed with this code.
130 lines isn't that complicated in the scheme of things.
Very good point. I added a whole section to the article, implementing the counting lines example with `make -j`,
which performs just as well as `xargs -P`
Yes this is true. Note BSD supports this better with Ctrl-T to generate SIGINFO, which one can send to any command even if not supported, in which case it's ignored. Using kill on linux, and having that kill processes by default is decidedly more awkward.
It's also worth noting the separate "progress" project which can be used to give the progress of running file based utilities.
We generally have pushed back on adding progress to each of the coreutils for these reasons, but the low overhead of implementation and high overlap with existing options was deemed enough to warrant adding this to dd
It comes from the DD (data definition) statement of OS/360 JCL, and hence why dd has the unusual option syntax compared to other unix utils
BTW if you are using dd to write usb drives etc. it's useful to bypass the Linux VM as much as possible to avoid systems stalls, especially with slow devices.
You can do that with O_DIRECT. Also dd recently got a progress option, so...
This machine isn't available yet :)
But since Lenovo is the Red Hat corp laptop vendor, support is generally excellent.
I've used Fedora 23+ on the Third gen X1 carbon with zero issues.