Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide option to extract selected files #5

Closed
MestreLion opened this issue Apr 11, 2013 · 5 comments
Closed

Provide option to extract selected files #5

MestreLion opened this issue Apr 11, 2013 · 5 comments
Assignees

Comments

@MestreLion
Copy link

This was reported in 2004 in Debian Bug Tracking System: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260174

A working patch ready to merge was also provided (tho the syntax is not optimal, better than -f FILE for a single file (or multiple -f) is to do as tar and many other tools: all arguments (not options) after the cabinet name are filenames to be extracted.

This is a very needed feature! And it is present in virtually all extractors, like zip, 7z, rar, tar, gz, etc. Much more useful, IMHO, than -c or -g (which I honestly have no idea what they are)

@twogood
Copy link
Owner

twogood commented Apr 11, 2013

It seems I was involved in the discussion back then, but probably forgot about it later. Thanks for reminding me!

@twogood
Copy link
Owner

twogood commented Apr 11, 2013

Please pull the repo and give it a try!

@twogood
Copy link
Owner

twogood commented Sep 4, 2013

Closing due to lack of feedback.

@twogood twogood closed this as completed Sep 4, 2013
@MestreLion
Copy link
Author

I'm sorry for the lack of feedback... at that time I didn't have a development environment where I could compile and run from source.

Reading the diff in commit 9b576e2 everything seems fine. My C is rusty, but it looks like you're looping every file in args after the .cab name. So no -f, which is great!

I'm not sure how fnmatch works, but if it accepts wildcards such as *.png (properly escaped so shell does not parse it), then awesome!

Also, it seems the loop recurses all paths by design, correct? Nice! If not, a -R option would be a nice addition in the future.

@twogood
Copy link
Owner

twogood commented Sep 5, 2013

No worries!

Please test the recursive stuff sometime... :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants