Support decompressing stdin #687
Labels
enhancement
New feature or request
Comments
|
Nice suggestion, this has been a suggestion for a couple years now and it's definitely something I'd merge in. |
|
Should we use a |
|
I believe And actually, this should probably be used for compression (and listing) too (tho decompression is a nice place to start). |
|
If |
rcorre
added a commit
to rcorre/ouch
that referenced
this issue
Jul 17, 2024
Fixes ouch-org#687. If "-" is passed as a filename, decompress data from stdin. Currently `--format` must be passed as well, but as a next step, we could try to infer the format from magic numbers. As stdin is not connected to the terminal, we cannot prompt for Y/N when warning about decompression in memory, for e.g. zip. Just default to No, and require passing "-y" in these cases. For zip, we have to buffer the whole stream in memory to seek into it, just as we do with a chained decoder like `.zip.bz`. The rar format requires an actual file (not an `impl Read`), so we write a temp file that it can decode. When decoding a single-file archive (e.g. file.bz), the output filename is just `-`, since we don't know the original filename. I had to add a bit of a hack to the tests to work around this. Another option would be to interpret "-d" as a destination filename in this case. When decoding a multi-file archive, I decided to unpack directly into the destination directory, as this seemed like a better experience than adding a top-level "-" folder inside the destination.
rcorre
added a commit
to rcorre/ouch
that referenced
this issue
Jul 17, 2024
Fixes ouch-org#687. If "-" is passed as a filename, decompress data from stdin. Currently `--format` must be passed as well, but as a next step, we could try to infer the format from magic numbers. As stdin is not connected to the terminal, we cannot prompt for Y/N when warning about decompression in memory, for e.g. zip. Just default to No, and require passing "-y" in these cases. For zip, we have to buffer the whole stream in memory to seek into it, just as we do with a chained decoder like `.zip.bz`. The rar format requires an actual file (not an `impl Read`), so we write a temp file that it can decode. When decoding a single-file archive (e.g. file.bz), the output filename is just `-`, since we don't know the original filename. I had to add a bit of a hack to the tests to work around this. Another option would be to interpret "-d" as a destination filename in this case. When decoding a multi-file archive, I decided to unpack directly into the destination directory, as this seemed like a better experience than adding a top-level "-" folder inside the destination.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With
tar, I can run something likecurl .../file.tar.gz | tar xvz. It would be nice ifouchsupported that for formats where streaming is possible.The text was updated successfully, but these errors were encountered: