forked from mdekauwe/CABLE_benchmarking
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Update usage of set -ex
#179
Merged
SeanBryan51
merged 1 commit into
main
from
174-excessive-output-in-job-script-from-set-ex
Oct 25, 2023
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we want to do this? To my understanding,
set -v
only outputs commands as they are read by the interpreter, not as they are executed as withset -x
. The level of tractability in errors will likely be reduced by switching these flags...Just throwing that wrench in there for discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
set -x
is useful when debugging complex bash scripts but I thought it was a bit overkill for it to be enabled by default for our use case (the only difference I see is-x
prints the$PS4
variable, and-v
does not).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree for now it looks like the difference between
set -x
andset -v
is only the$PS4
variable. @bschroeter do you have an example to show if-x
is better than-v
. At the same time, if the difference is that small, I don't care which one is used.But I am wondering if we should keep
set -e
at the start of the script. Otherwise, if amodule load
fails, it will keep going through and possibly never fail (if it fails when running CABLE, currently it does not fail) or only fail quite some time afterwards. We could moveset -v
/set -x
only before thebenchcab
commands.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ccarouge, I'll see if I can find a test that compares the two. I'm also of the opinion that if the difference is negligible then it doesn't really matter that much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Internet gives us the following answer:
Personally I prefer to get in the habit of setting
-ex
purely to get the exact place and stack trace of the error, with more information regarding the nature of the failure. We used to use this (and pipefail) excessively at BNOC. However, I accept that it might not be necessary here and is adding to noise.I'll leave it up to your discretion on which way to go. I'm happy either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this as too big of a deal as we can let benchcab crash if the module load step fails. I'm happy to keep the strict error checking for executing benchcab specific commands and not for external dependencies like environment modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay in coming back to this.
Let's start with what is currently in the code. We can change later if we have a use case for it.