question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

make shell scripts more strict

See original GitHub issue

shell scripts by default skip over errors and continue. it’s best practices to use set to harden this using the following flags:

  • -e: Exit immediately if a command exits with a non-zero status.
  • -u: Treat unset variables as an error when substituting.
  • possibly also -o pipefail: If set, the return value of a pipeline is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands in the pipeline exit successfully. By default, pipelines only return a failure if the last command errors. When used in combination with set -e, pipefail will make a script exit if any command in a pipeline errors.

so far i’ve used set -eu, but i’ve seen that OpenSearch has also used set -e -o pipefail (see example below).

i think somebody with expert knowledge in this area (i wouldn’t consider myself an expert here) should define the standard to be used in all scripts (or rules for when to use what if there are differentiating needs).

some scripts already have this set, e.g.: https://github.com/opensearch-project/OpenSearch/blob/c8ac0373895fe6b884792569029bdc9d465850b5/distribution/src/bin/opensearch-env#L3

others don’t, e.g. https://github.com/opensearch-project/OpenSearch/blob/main/distribution/packages/src/deb/init.d/opensearch

this is relevant not just for this repository but for all repositories (i’m not aware of a meta-repository where to open such tickets, feel free to move this ticket if such a place exists).

standardising and applying this globally will ensure that errors are not (silently) hidden.

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:1
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
CEHENKLEcommented, May 10, 2022

Hey @rursprung ! I agree, standardizing this would keep us from falling into pits, which is always good.

We have a couple of global-ish repos like clients/plugins/meta. @dblock do you have a thought on where this should go?

At the very least, we could set up the defaults in core (opensearch-project/opensearch) while we figure out the right way to track it against all repos. @owaiskazi19 can you take a swing at that for core?

1reaction
dblockcommented, May 10, 2022

I would start doing this work here, then we can expand it into a campaign which likely belongs in project-meta.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Use Bash Strict Mode (Unless You Love Debugging)
Use Bash Strict Mode (Unless You Love Debugging). Let's start with the punchline. Your bash scripts will be more robust, reliable and maintainable...
Read more >
Bash strict mode and why you should care | PoorlyWritten
Composing advanced strict modes is not only making bash a language that is more sane, is also getting further from the collective experience ......
Read more >
Shell scripts should be run in strict mode by default : TW-51710
If there is more than one step in the script, for example: ... You can create your own Strict Shell runner and use...
Read more >
Shell Scripts Matter - Thiht's blog
The unofficial strict mode is more intrusive than what we've seen before and can be hard to deal with, but it's worth it...
Read more >
Shell strict mode - steinbaugh.com
Make the shell stricter by default using set built-in. ... For bash scripts, this one-liner can be placed under the shebang line.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found