# `ark` - Archiving and compression toolkit with a simple, obvious interface

`ark` is a tool for creating and extracting archives, and (eventually) for compressing and decompressing files. It aims to support the most common operations on a broad variety of formats: `tar`, `zip`, `7z`, `ar`, etc. 

## Features

* Intuitive, subcommand-based interface
* Automatically infers archive format and compression algorithm from filenames
* Cross-platform, supporting Windows/Mac/Linux (only tested on Linux so far)
* Optionally respects `.gitignore` files (not yet implemented)
* Optionally deduplicates top-level directory when extracting, in the event that the archive is being extracted into a directory with the same name as the top-level directory _inside_ the archive. (not yet implemented)
* Tree view when listing contents of an archive (not yet implemented)

## Examples

```sh
# Create an archive
ark pack somedir archive.tar.gz

# Like mv or cp, the last argument is interpreted as the destination
ark pack file1 file2 anotherdir archive.zip

# You can explicitly specify the format/compression, in case you need to do something weird
ark pack --format zip --compression deflate files/* archive.vl2

# Unpack an archive into the current directory
ark unpack archive.tar.gz

# Automatically creates destination directory if not extant
ark unpack archive.tar.gz somedir

# Deduplicate top-level directory (i.e. if "targetdir" is the root of all paths in the archive,
# this will prevent the output tree from starting with targetdir/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.)