Support decompressing stdin. #692
Conversation
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.
|
Thanks for such a detailed description of every choice you made, that helps a lot. This is a very good PR.
Those are indeed weird cases to deal with. Having an output file named About unpacking in the current folder instead of using the What do you think? |
|
Thanks for taking a look!
I'm fine with either of those, but I'm not sure where the extensions would come from.
As a consumer, I feel like the most convenient behavior is:
That being said, I get that it's weird for stdin to change the behavior of |
It would come from
Hahaha yeah that's what I was thinking, if we add special cases for the behavior of It's also hard to remember why after some years. So can you change it to write to a "stdin-output" (or other name?) file and folder, respectively, for the single-file and multi-file archive? Then we think about extensions later. (The problem with inferring the extension from |
Fixes:
```
error: doc list item missing indentation
--> src/commands/decompress.rs:237:5
|
237 | /// Note: This functions assumes that `output_dir` exists
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
= note: `-D clippy::doc-lazy-continuation` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::doc_lazy_continuation)]`
help: indent this line
|
237 | /// Note: This functions assumes that `output_dir` exists
| ++
```
|
aarch/musl build failures seem unrelated: |
|
Can't believe 3 weeks went by, sorry, time flies sometimes. I'll try to get back to this this weekend. |
|
No rush, I know how it goes. Thanks for checking in! |
|
Alright so I need to dedicate a bit of time to figure out why CI failed randomly, but I don't think this PR needs to wait for it. Thank you so much for the contribution! :) This is a great one. |
Fixes #687.
If "-" is passed as a filename, decompress data from stdin.
Currently
--formatmust 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), sowe 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 adda 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.