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

Throw errors and/or don't consume next option when OPTARG missing #5

Open
zbeekman opened this issue Feb 16, 2016 · 2 comments
Open
Assignees

Comments

@zbeekman
Copy link
Collaborator

$ LOG_LEVEL=7 /bin/bash -o pipefail -o nounset -o errexit ./main.sh -f -t
2016-02-16 16:27:12 UTC [    debug] cli arg arg_f = () -> -t
2016-02-16 16:27:12 UTC [     info] You are on OSX
2016-02-16 16:27:12 UTC [    debug] Info useful to developers for debugging the application, not useful during operations.
2016-02-16 16:27:12 UTC [     info] Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.
2016-02-16 16:27:12 UTC [   notice] Events that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required.
2016-02-16 16:27:12 UTC [  warning] Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time. This is a debug message
2016-02-16 16:27:12 UTC [    error] Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time.
2016-02-16 16:27:12 UTC [ critical] Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection.
2016-02-16 16:27:12 UTC [    alert] Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection.
2016-02-16 16:27:12 UTC [emergency] A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call.
2016-02-16 16:27:12 UTC [     info] Cleaning up. Done
@zbeekman
Copy link
Collaborator Author

perhaps this should be marked won't fix... I'll research what unix tools and similar do in this case

@kvz
Copy link
Owner

kvz commented Mar 17, 2016

Failing hard in this case seems like a good idea. At least when options are defined that is.

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