Naa, tar handles archives, it should know how to archive and unarchive really well. It shouldn’t know how to compress or un compress or sort it’s output by human readable file sizes. If you add the -z or -j, for example, to your tar command, tar will filter your archive through gunzip or bunzip prior to doing it’s job of un archiving all your files. If you use the -f flag, tar will spit out a list of files that were operated on. Adding a sort -h feature to tar would violate the unix philosophy.
So… tar x should really be a separate program than tar c? They’re doing different functions
Naa, tar handles archives, it should know how to archive and unarchive really well. It shouldn’t know how to compress or un compress or sort it’s output by human readable file sizes. If you add the -z or -j, for example, to your tar command, tar will filter your archive through gunzip or bunzip prior to doing it’s job of un archiving all your files. If you use the -f flag, tar will spit out a list of files that were operated on. Adding a sort -h feature to tar would violate the unix philosophy.
Yes, like
gzipandgunzipWhat if I write a program that checks argv[0] to decide which part of the code to run, and makes a bunch of symlinks
That’s actually what BusyBox does I think. You have one executable for everything and it changes the behavior according to argv[0].
Then that would kind of defeat the purpose
But it’s not like you /have/ to adhere to the Unix philosophy or anything