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

--appimage-extract <non-existant-file> exits 0 and no error message #866

Open
HaleTom opened this Issue Oct 10, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@HaleTom
Copy link

HaleTom commented Oct 10, 2018

I would expect that trying to extract a file which doesn't exist in the image would exit non-0.

<appimage> --appimage-extract <non-existant-file>

What I get is a null output and a 0 exit code (which by convention means that everything worked OK)

The exit code can be viewed with a POSIX compatible shell via: echo $?

Likewise I expect a human-readable error message when any of the requested files don't exist in the image.

@TheAssassin

This comment has been minimized.

Copy link
Member

TheAssassin commented Oct 10, 2018

@HaleTom the syntax is my.AppImage --appimage-extract, that will extract my.AppImage to squashfs-root. I'm not sure what you're trying to do, please add more details.

@probonopd

This comment has been minimized.

Copy link
Member

probonopd commented Oct 11, 2018

Likely my.AppImage --appimage-extract /some/non/extisting.file

@HaleTom HaleTom changed the title --appimage-extract <non-existant-file> returns 0 --appimage-extract <non-existant-file> exits 0 and no error message Oct 11, 2018

@HaleTom

This comment has been minimized.

Copy link

HaleTom commented Oct 11, 2018

Sorry, that wasn't clear. I've updated the top post.

@probonopd probonopd added the bug label Oct 11, 2018

@probonopd

This comment has been minimized.

Copy link
Member

probonopd commented Oct 11, 2018

In another place we determined that in case of errors we should print a message but nevertheless continue extracting: #834

Keep in mind that --appimage-extract supports extracting multiple files using wildcards; thus I think this should apply here too. Just exiting with 1 on the first file that fails may be more concise but would also prevent users from extracting files that would otherwise be possible to be extracted.

@HaleTom

This comment has been minimized.

Copy link

HaleTom commented Oct 11, 2018

@probonopd FYI I am aware of #363 and am already working around it.

I agree that exiting 1 immediately is premature, but if any part of the command failed I'd expect a non-0 exit code.

Possibly exit 2 for "a requested file doesn't exist" and exit 1 for IO error or other?

@probonopd

This comment has been minimized.

Copy link
Member

probonopd commented Oct 11, 2018

PR highly welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment