jfmonty2/ark
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

needless self-justification

Browse Source
This commit is contained in:
Joseph Montanaro 2024-02-20 08:04:32 -08:00
parent f8ba5c1f0b
commit 7cfaffb4b7
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -33,3 +33,15 @@ ark unpack archive.tar.gz somedir
# this will prevent the output tree from starting with targetdir/targetdir) # this will prevent the output tree from starting with targetdir/targetdir)
ark unpack archive.tar.xz --deduplicate targetdir ark unpack archive.tar.xz --deduplicate targetdir
``` ```
## What was wrong with `tar`?
GNU `tar` is an amazing tool, and it's stood the test of time impressively well. I don't expect `ark` to replace `tar`, nor would I want it to - `tar` has many features and uses that would make no sense for `ark`, starting with its titular **t**ape **ar**chiving capability.
However, "standing the test of time" can cut both ways. In the time since `tar` was initially created (which happened in 1979 according to Wikipedia), an set of informal but widely accepted standards have grown up around user interfaces. This is particularly evident in GUIs, but CLIs also have developed conventions (such as subcommands) to which `tar` doesn't adhere. As usual, xkcd [says it best](https://xkcd.com/1168/):
![XKCD comid #1168, satirizing the unintelligiibility of "tar" commands](https://imgs.xkcd.com/comics/tar.png)
I think there's room for an alternative to `tar` for its most common day-to-day use cases, such as creating, extracting, and listing archives.
I wanted more than that, though. I also wanted to be able to manage additional archive formats such as `ZIP` and `7z`, rather than having to remember a separate tool for every type of archive. Similarly, I wanted to be able to easily compress and decompress files with a single tool that handles many compression algorithms. (Admittedly this desire is lower-priority since pure compression-only tools are typically quite simple to use.)