Disable smart unpack when --dir is provided

[marcospb19]

When decompressing an archive, there is a risk of messing up the current folder, if the archive is huge it will mix your folder with a lot of files and you'll have a hard time trying to clean it up afterwards.

To solve this, Ouch has a hidden feature called "smart unpack", when it detects that an archive has more than one file, it creates a new folder and unpacks all the contents inside of that folder, so cleaning up is as simple as deleting that folder.

However, if the user specified a target directory with --dir, we could (?) assume they intentionally want to decompress it into that folder directly, so "smart unpack" can be disabled, it will just create an unwanted nested folder.

[marcospb19]

This is a follow-up to #321 (kinda), having this kind of specific and unpredictable behavior for smart unpack makes me question if we have a better solution for this, and if this feature is worth having. What do you think @a-moreira @figsoda?

I still think we need a way to protect the user from messing it up, I run into this problem often, a --revert or --cleanup flag on the decompression operation would solve it, but is it less complex than smart unpack? Maybe even a cleanup subcommand instead of some flag.

[a-moreira]

if the user specified a target directory with --dir, we could (?) assume they intentionally want to decompress it into that folder directly, so "smart unpack" can be disabled, it will just create an unwanted nested folder

I agree. With decompressing tools, I generally expect this behavior:

• If my archive simply has multiple files (meaning it's a compressed set of files, not a compressed folder with files), then I expect the files to be just dumped on the current (or specified) directory after decompressing.
• if my archive is a compressed folder, then it should be decompressed as a folder with its files inside.

The smart unpack feature caught me off-guard when testing this application, indeed.
As a possible protection for the user, a revert subcommand would be interesting, but as a starter we could simply add a warning printed to stdout and ask for confirmation.
Wdyt?

[figsoda]

I would argue that smart unpack should be behind a flag, and --dir should just work as if we cded before unpacking, which I'm not sure is the behavior right now

[marcospb19]

@figsoda

--dir should just work as if we cded before unpacking, which I'm not sure is the behavior right now

Yeah that's the current behavior I was complaining about.

---

Just to clarify, here's an explanation of what Smart Unpack does from the user POV:

1. For each file you're decompressing.
2. If file is an archive, and.
3. If it contains multiple files at the root of the archive.
4. Go to the folder where decompression should be done (considering --dir).
5. Create a new folder inside of it, with the name of the archive file name.
6. Do decompression inside this new folder.

This explanation ignores the implementation details because those can change at any time.

---

Both of you agreed that smart unpack shouldn't be the default.

I'm against just removing it right now without a better replacement because I feel like it's handy, sometimes I unpack an archive expecting some layout, and I get surprises.

About adding it as a flag (-s/--smart), if it is behind a flag I don't expect people to be using it most of the time, so we can't protect the users.

I might sound a bit crazy with this "protect the users" stuff, it's a CLI tool and CLI tools often don't care much, but at the same time, if we don't do anything then we take the L and accept that decompression via CLI is worse than doing it with GUI, GUI tools like Nautilus always create a dedicated folder with the name of the archive to keep things simple and avoid these problems, and that has always been great.

As a possible protection for the user, a revert subcommand would be interesting, but as a starter we could simply add a warning printed to stdout and ask for confirmation.

🤔 could work, but I'm not comfortable answering too many questions (one for each archive with multiple files in its root), I'm assuming it's a Y/N question, and not three options (cancel, unpack here, unpack in new folder).

[marcospb19]

This explanation ignores the implementation details because those can change at any time.

Currently, Smart Unpack creates a temporary directory, decompresses inside, and moves stuff to the correct location.

It's possible to refactor it and avoid having to create a temporary directory and move stuff around.

I haven't created an issue for this refac yet because we aren't sure if this feature will be removed or not.

[NiceGuyIT]

From a user standpoint, I would like any/all of the following.

1. Control the directory name with the --dir option.
2. Have the directory name be "smarter".
3. Disable Smart Unpack with some flag: --no-smart-unpack
4. Be able to extract a single file from the archive (Extract specific files/folders from archives #342).

The current implementation is not logical. I'm using doggo as an example.

1. ouch decompress --dir doggo_0.5.5_linux_amd64 doggo_0.5.5_linux_amd64.tar.gz produces the following. Notice the extra directory level.

doggo_0.5.5_linux_amd64
└── doggo_0.5
    ├── completions
    │   ├── doggo.fish
    │   └── doggo.zsh
    ├── doggo
    ├── doggo-api.bin
    ├── LICENSE
    └── README.md

2. I don't know why ouch chose doggo_0.5 for the smart directory. It would be nice if it chose doggo_0.5.5_linux_amd64, the filename without the compression extensions, or doggo_0, the minimal basename. Should this be a separate issue?

[marcospb19]

Thanks for the input.

About doggo_0.5, yeah can you please create a new issue for that? That naming is unreasonable 😄.