That head/tail thing is kind of a goofy argument. For one thing they aren’t duals; tail is naturally more complex because the end of a file often changes and the application can optionally keep showing you the new output. Also, the fact that they’re separate applications in the first place is arguably better than the a one-application approach, which would always require a command line switch to select between outputting the start or end of a file. And finally, while I guess this could vary between implementations of head and tail, mine has identical switches for all the common options.
I initially agreed with your take there but I actually think they’re a great argument for their point. head and tail are the exact same abstraction. Their implementations will be quite different, but they both serve “provided this data, give me these lines”. Consider instead that these are simply operations on arrays and actually they map perfectly to Python slices: data[:10] and data[-10:]. This abstraction mapping also shows that, imo, the tool should provide data[n:m] and it would still be entirely consistent with the Unix philosophy. In fact, this tool exists in the Unix toolkit: sed -n n,mp. Three tools then are currently required for the simple concept of “slice lines”. I also think it’s a bit of a mess. You could replace head with sed fairly easily: sed -n '1,10p' but not tail (it is possible, but quite slow and very opaque)
As an aside I actually found this quite frustrating myself because I don’t like reaching for sed in the n:m case (I always forget and end up piping head to tail) and ended up writing my own tool for essentially this style of slicing input, also replacing probably my least favorite use of my least favorite Unix tool, dd, to slice arbitrary byte sequences. The tool doesn’t feel overloaded and I use it quite often.
(I’m sure many people have written this same tool. There is probably a widely known open source option that I’ve just never come across)
They could have been two commands that call a single parent command with different options. For example, imagine if cat had an option -N to restrict the number of lines that was printed, and also an option -t to start from the end. head would just proxy to cat -N and tail would proxy to cat -N -t. Combining the three into a single implementation reduces total LoC and opportunity for bugs. Also reduces total maintenance burden.
I believe busybox is like this actually - a ton of Unix commands in a single package. It’s used by Alpine Linux, a tiny and performance linux distro commonly used by docker containers.
Some quick research says that it is indeed a re-implementation. The first line of the wikipedia, says:
BusyBox is an implementation of many Unix commands in a single executable file.
You can download the source code yourself to verify. And if you’ve actually used Alpine Linux before you would have also noticed that the commands provided by busybox have only a subset of the options provided by their GNU coreutils counterparts.
Please do your research before so confidently correcting other people.
That head/tail thing is kind of a goofy argument. For one thing they aren’t duals;
tailis naturally more complex because the end of a file often changes and the application can optionally keep showing you the new output. Also, the fact that they’re separate applications in the first place is arguably better than the a one-application approach, which would always require a command line switch to select between outputting the start or end of a file. And finally, while I guess this could vary between implementations ofheadandtail, mine has identical switches for all the common options.I initially agreed with your take there but I actually think they’re a great argument for their point.
headandtailare the exact same abstraction. Their implementations will be quite different, but they both serve “provided this data, give me these lines”. Consider instead that these are simply operations on arrays and actually they map perfectly to Python slices:data[:10]anddata[-10:]. This abstraction mapping also shows that, imo, the tool should providedata[n:m]and it would still be entirely consistent with the Unix philosophy. In fact, this tool exists in the Unix toolkit:sed -n n,mp. Three tools then are currently required for the simple concept of “slice lines”. I also think it’s a bit of a mess. You could replaceheadwithsedfairly easily:sed -n '1,10p'but nottail(it is possible, but quite slow and very opaque)As an aside I actually found this quite frustrating myself because I don’t like reaching for
sedin then:mcase (I always forget and end up pipingheadtotail) and ended up writing my own tool for essentially this style of slicing input, also replacing probably my least favorite use of my least favorite Unix tool,dd, to slice arbitrary byte sequences. The tool doesn’t feel overloaded and I use it quite often.(I’m sure many people have written this same tool. There is probably a widely known open source option that I’ve just never come across)
They could have been two commands that call a single parent command with different options. For example, imagine if
cathad an option-Nto restrict the number of lines that was printed, and also an option-tto start from the end.headwould just proxy tocat -Nand tail would proxy tocat -N -t. Combining the three into a single implementation reduces total LoC and opportunity for bugs. Also reduces total maintenance burden.I believe
busyboxis like this actually - a ton of Unix commands in a single package. It’s used by Alpine Linux, a tiny and performance linux distro commonly used by docker containers.Busybox is literally just a bundle. That’s its whole purpose. It doesn’t reimplement anything.
Some quick research says that it is indeed a re-implementation. The first line of the wikipedia, says:
You can download the source code yourself to verify. And if you’ve actually used Alpine Linux before you would have also noticed that the commands provided by busybox have only a subset of the options provided by their GNU coreutils counterparts.
Please do your research before so confidently correcting other people.