Implement -e/--extract

[keysym]

2

[keysym]

• Isn't better to make --extract receive a directory path to write, with the current directory as default?
• The extraction here overwrites files. Would be nice to have a -o/--overwrite to explicit allow this behavior?

[Morganamilo]

Start of entry is not the start of the file so the open and writes need to be separate.

For 1. Maybe some sort of option can be added in future. For 2 I don't think it matters much.

[keysym]

Start of entry is not the start of the file so the open and writes need to be separate.

compress_tools::uncompress_archive_file() doesn't care about the ArchiveContents it's on. Just pass a _"compressedarchive", a "target" and a _"path_to_the_file_inside_the_compressedarchive" and it'll just uncompress the specified file to the target. Having this inside if is_match() inside StartOfEntry is enough here as we just care if the file is matched.

There's also the possibility of opening a target File and calling .write_all(ChunkData), then separating the open and write makes sense. This seems better 'cause it avoids the re-opening of the source pkg, but opening it outside the loop doesn't seem so that wrong.

Sorry if this comment is a formatting mess

[Morganamilo]

Ah right, thought I'd comment from mobile quickly so missed the call to extract file.

There's also the possibility of opening a target File and calling .write_all(ChunkData), then separating the open and write makes sense. This seems better 'cause it avoids the re-opening of the source pkg, but opening it outside the loop doesn't seem so that wrong.

This is what I was thinking and still think is the way to go.

[keysym]

I've moved the quiet logic to make paccat <package> --extract --quiet -- <file> work together. I made this PR a Draft 'cause I want to know if it's a desired behavior, and I'll clear the code.

Do you think they should not interact together?!

[Morganamilo]

Well my idea is that extract may as well print the file name anyway so in that sense they work together as extract would imply quiet. But I still don't see why you moved the quiet code into the data reading.

[keysym]

Well my idea is that extract may as well print the file name anyway so in that sense they work together as extract would imply quiet.

So, --extract will always be quiet, right?!

But I still don't see why you moved the quiet code into the data reading.

In master, quiet causes skip, so it would never read the data do be extracted. So if --quiet needs to read the data to conditionally extract, it made sense to move it

[Morganamilo]

Extract should just print the filename instead printing the file data. Yes this is what quiet does but it still should be in the start of file section.

[Morganamilo]

Everything looks good now, thanks.

[keysym]

@Morganamilo Thanks for the reviews and the patience!