diff options
| -rw-r--r-- | gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi | 64 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 343 | ||||
| -rw-r--r-- | index.gmi | 2 | ||||
| -rw-r--r-- | uptime-stats.gmi | 2 |
4 files changed, 241 insertions, 170 deletions
diff --git a/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi b/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi index 4f386850..6831f7e1 100644 --- a/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi +++ b/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi @@ -27,13 +27,13 @@ These are my modifications to the Google Guide. Google recommends using always... -``` +```bash #!/bin/bash ``` ... as the shebang line, but that does not work on all Unix and Unix-like operating systems (e.g., the *BSDs don't have Bash installed to /bin/bash). Better is: -``` +```bash #!/usr/bin/env bash ``` @@ -51,7 +51,7 @@ I hit the 80 character line length quicker with the four spaces than with two sp Google recommends breaking up long pipes like this: -``` +```bash # All fits on one line command1 | command2 @@ -64,7 +64,7 @@ command1 \ I think there is a better way like the following, which is less noisy. The pipe | already indicates the Bash that another command is expected, thus making the explicit line breaks with \ obsolete: -``` +```bash # Long commands command1 | command2 | @@ -72,11 +72,13 @@ command1 | command4 ``` +> Update: It's 2023 now, and I have changed my mind. I think Google's way is the better one. It may be a bit more to type, but the leading `|` are a nice eye catcher, so you know immediately what is going on! + ### Quoting your variables Google recommends always quote your variables. Generally, it would be best if you did that only for variables where you are unsure about the content/values of the variables (e.g., content is from an external input source and may contain whitespace or other special characters). In my opinion, the code will become quite noisy when you always quote your variables like this: -``` +```bash greet () { local -r greeting="${1}" local -r name="${2}" @@ -86,7 +88,7 @@ greet () { In this particular example, I agree that you should quote them as you don't know the input (are there, for example, whitespace characters?). But if you are sure that you are only using simple bare words, then I think that the code looks much cleaner when you do this instead: -``` +```bash say_hello_to_paul () { local -r greeting=Hello local -r name=Paul @@ -96,7 +98,7 @@ say_hello_to_paul () { You see, I also omitted the curly braces { } around the variables. I only use the curly braces around variables when it makes the code either easier/clearer to read or if it is necessary to use them: -``` +```bash declare FOO=bar # Curly braces around FOO are necessary echo "foo${FOO}baz" @@ -108,7 +110,7 @@ A few more words on always quoting the variables: For the sake of consistency (a Google recommends using the built-in commands over available external commands where possible: -``` +```bash # Prefer this: addition=$(( X + Y )) substitution="${string/#foo/bar}" @@ -132,7 +134,7 @@ I even didn't get started with what you can do with awk (especially GNU Awk), a Bash does not support a boolean type. I tend just to use the strings 'yes' and 'no' here. I used 0 for false and 1 for true for some time, but I think that the yes/no strings are easier to read. Yes, the Bash script would need to perform string comparisons on every check, but if performance is crucial to you, you wouldn't want to use a Bash script anyway, correct? -``` +```bash declare -r SUGAR_FREE=yes declare -r I_NEED_THE_BUZZ=no @@ -153,14 +155,13 @@ buy_soda $I_NEED_THE_BUZZ Google is in the opinion that eval should be avoided. I think so too. They list these examples in their guide: -``` +```bash # What does this set? # Did it succeed? In part or whole? eval $(set_my_variables) # What happens if one of the returned values has a space in it? variable="$(eval some_function)" - ``` However, if I want to read variables from another file, I don't have to use eval here. I only have to source the file: @@ -195,7 +196,7 @@ The downside is that ShellCheck won't be able to follow the dynamic sourcing any When I do list processing in Bash, I prefer to use pipes. You can chain them through Bash functions as well, which is pretty neat. Usually, my list processing scripts are of a structure like this: -``` +```bash filter_lines () { echo 'Start filtering lines in a fancy way!' >&2 grep ... | sed .... @@ -239,35 +240,38 @@ I often refactor existing Bash code. That leads me to add and removing function The solution is to use of the "assign-then-shift"-method, which goes like this: "local -r var1=$1; shift; local -r var2=$1; shift". The idea is that you only use "$1" to assign function arguments to named (better readable) local function variables. You will never have to bother about "$2" or above. That is very useful when you constantly refactor your code and remove or add function arguments. It's something that I picked up from a colleague (a pure Bash wizard) some time ago: -``` +```bash some_function () { local -r param_foo="$1"; shift local -r param_baz="$1"; shift local -r param_bay="$1"; shift - ... + + # ... } ``` Want to add a param_baz? Just do this: -``` +```bash some_function () { local -r param_foo="$1"; shift local -r param_bar="$1"; shift local -r param_baz="$1"; shift local -r param_bay="$1"; shift - ... + + # ... } ``` Want to remove param_foo? Nothing easier than that: -``` +```bash some_function () { local -r param_bar="$1"; shift local -r param_baz="$1"; shift local -r param_bay="$1"; shift - ... + + # ... } ``` @@ -277,7 +281,7 @@ As you can see, I didn't need to change any other assignments within the functio I call this the paranoid mode. The Bash will stop executing when a command exits with a status not equal to 0: -``` +```bash set -e grep -q foo <<< bar echo Jo @@ -285,14 +289,14 @@ echo Jo Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to run in paranoid mode purely, so there must be a way to add exceptions. Critical Bash scripts of mine tend to look like this: -``` +```bash #!/usr/bin/env bash set -e some_function () { - .. some critical code - ... + # .. some critical code + # ... set +e # Grep might fail, but that's OK now @@ -300,11 +304,11 @@ some_function () { local -i ec=$? set -e - .. critical code continues ... + # .. critical code continues ... if [[ $ec -ne 0 ]]; then - ... + : # ... fi - ... + # ... } ``` @@ -316,7 +320,7 @@ There are also a couple of things I've learned from Google's guide. The following looks like a valid Bash code: -``` +```bash if [[ "${my_var}" > 3 ]]; then # True for 4, false for 22. do_something @@ -325,7 +329,7 @@ fi ... but it is probably an unintended lexicographical comparison. A correct way would be: -``` +```bash if (( my_var > 3 )); then do_something fi @@ -333,7 +337,7 @@ fi or -``` +```bash if [[ "${my_var}" -gt 3 ]]; then do_something fi @@ -345,7 +349,7 @@ I have never used the PIPESTATUS variable before. I knew that it's there, but I The PIPESTATUS variable in Bash allows checking of the return code from all parts of a pipe. If it's only necessary to check the success or failure of the whole pipe, then the following is acceptable: -``` +```bash tar -cf - ./* | ( cd "${dir}" && tar -xf - ) if (( PIPESTATUS[0] != 0 || PIPESTATUS[1] != 0 )); then echo "Unable to tar files to ${dir}" >&2 @@ -354,7 +358,7 @@ fi However, as PIPESTATUS will be overwritten as soon as you do any other command, if you need to act differently on errors based on where it happened in the pipe, you'll need to assign PIPESTATUS to another variable immediately after running the command (don't forget that [ is a command and will wipe out PIPESTATUS). -``` +```bash tar -cf - ./* | ( cd "${DIR}" && tar -xf - ) return_codes=( "${PIPESTATUS[@]}" ) if (( return_codes[0] != 0 )); then diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 2c16b8bb..0a415179 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> - <updated>2023-12-10T11:46:05+02:00</updated> + <updated>2023-12-10T17:11:56+02:00</updated> <title>foo.zone feed</title> <subtitle>To be in the .zone!</subtitle> <link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" /> @@ -8105,14 +8105,20 @@ assert<font color="#990000">::</font>equals <font color="#FF0000">"$(generate::m <br /> <span>Google recommends using always...</span><br /> <br /> -<pre> -#!/bin/bash +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900">#!/bin/bash </font></i> </pre> <br /> <span>... as the shebang line, but that does not work on all Unix and Unix-like operating systems (e.g., the *BSDs don't have Bash installed to /bin/bash). Better is:</span><br /> <br /> -<pre> -#!/usr/bin/env bash +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900">#!/usr/bin/env bash</font></i> </pre> <br /> <h3 style='display: inline'>Two space soft-tabs indentation</h3><br /> @@ -8129,55 +8135,72 @@ assert<font color="#990000">::</font>equals <font color="#FF0000">"$(generate::m <br /> <span>Google recommends breaking up long pipes like this:</span><br /> <br /> -<pre> -# All fits on one line -command1 | command2 +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900"># All fits on one line</font></i> +command1 <font color="#990000">|</font> command2 -# Long commands -command1 \ - | command2 \ - | command3 \ - | command4 +<i><font color="#9A1900"># Long commands</font></i> +command1 <font color="#990000">\</font> + <font color="#990000">|</font> command2 <font color="#990000">\</font> + <font color="#990000">|</font> command3 <font color="#990000">\</font> + <font color="#990000">|</font> command4 </pre> <br /> <span>I think there is a better way like the following, which is less noisy. The pipe | already indicates the Bash that another command is expected, thus making the explicit line breaks with \ obsolete:</span><br /> <br /> -<pre> -# Long commands -command1 | - command2 | - command3 | +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900"># Long commands</font></i> +command1 <font color="#990000">|</font> + command2 <font color="#990000">|</font> + command3 <font color="#990000">|</font> command4 </pre> <br /> +<span class='quote'>Update: It's 2023 now, and I have changed my mind. I think Google's way is the better one. It may be a bit more to type, but the leading <span class='inlinecode'>|</span> are a nice eye catcher, so you know immediately what is going on!</span><br /> +<br /> <h3 style='display: inline'>Quoting your variables</h3><br /> <br /> <span>Google recommends always quote your variables. Generally, it would be best if you did that only for variables where you are unsure about the content/values of the variables (e.g., content is from an external input source and may contain whitespace or other special characters). In my opinion, the code will become quite noisy when you always quote your variables like this:</span><br /> <br /> -<pre> -greet () { - local -r greeting="${1}" - local -r name="${2}" - echo "${greeting} ${name}!" +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">greet ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">greeting</font><font color="#990000">=</font><font color="#FF0000">"${1}"</font> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">name</font><font color="#990000">=</font><font color="#FF0000">"${2}"</font> + echo <font color="#FF0000">"${greeting} ${name}!"</font> } </pre> <br /> <span>In this particular example, I agree that you should quote them as you don't know the input (are there, for example, whitespace characters?). But if you are sure that you are only using simple bare words, then I think that the code looks much cleaner when you do this instead:</span><br /> <br /> -<pre> -say_hello_to_paul () { - local -r greeting=Hello - local -r name=Paul - echo "$greeting $name!" +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">say_hello_to_paul ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">greeting</font><font color="#990000">=</font>Hello + <b><font color="#0000FF">local</font></b> -r <font color="#009900">name</font><font color="#990000">=</font>Paul + echo <font color="#FF0000">"$greeting $name!"</font> } </pre> <br /> <span>You see, I also omitted the curly braces { } around the variables. I only use the curly braces around variables when it makes the code either easier/clearer to read or if it is necessary to use them:</span><br /> <br /> -<pre> -declare FOO=bar -# Curly braces around FOO are necessary -echo "foo${FOO}baz" +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">declare</font></b> <font color="#009900">FOO</font><font color="#990000">=</font>bar +<i><font color="#9A1900"># Curly braces around FOO are necessary</font></i> +echo <font color="#FF0000">"foo${FOO}baz"</font> </pre> <br /> <span>A few more words on always quoting the variables: For the sake of consistency (and for making ShellCheck happy), I am not against quoting everything I encounter. I also think that the larger the Bash script becomes, the more critical it becomes always to quote variables. That's because it will be more likely that you might not remember that some of the functions don't work on values with spaces in them, for example. It's just that I won't quote everything in every small script I write. </span><br /> @@ -8186,14 +8209,17 @@ echo "foo${FOO}baz" <br /> <span>Google recommends using the built-in commands over available external commands where possible:</span><br /> <br /> -<pre> -# Prefer this: -addition=$(( X + Y )) -substitution="${string/#foo/bar}" +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900"># Prefer this:</font></i> +<font color="#009900">addition</font><font color="#990000">=</font><font color="#009900">$(</font><font color="#990000">(</font> X <font color="#990000">+</font> Y <font color="#990000">))</font> +<font color="#009900">substitution</font><font color="#990000">=</font><font color="#FF0000">"${string/#foo/bar}"</font> -# Instead of this: -addition="$(expr "${X}" + "${Y}")" -substitution="$(echo "${string}" | sed -e 's/^foo/bar/')" +<i><font color="#9A1900"># Instead of this:</font></i> +<font color="#009900">addition</font><font color="#990000">=</font><font color="#FF0000">"$(expr "</font><font color="#009900">${X}</font><font color="#FF0000">" + "</font><font color="#009900">${Y}</font><font color="#FF0000">")"</font> +<font color="#009900">substitution</font><font color="#990000">=</font><font color="#FF0000">"$(echo "</font><font color="#009900">${string}</font><font color="#FF0000">" | sed -e 's/^foo/bar/')"</font> </pre> <br /> <span>I can't entirely agree here. The external commands (especially sed) are much more sophisticated and powerful than the built-in Bash versions. Sed can do much more than the Bash can ever do by itself when it comes to text manipulation (the name "sed" stands for streaming editor, after all).</span><br /> @@ -8210,35 +8236,40 @@ substitution="$(echo "${string}" | sed -e 's/^foo/bar/')" <br /> <span>Bash does not support a boolean type. I tend just to use the strings 'yes' and 'no' here. I used 0 for false and 1 for true for some time, but I think that the yes/no strings are easier to read. Yes, the Bash script would need to perform string comparisons on every check, but if performance is crucial to you, you wouldn't want to use a Bash script anyway, correct?</span><br /> <br /> -<pre> -declare -r SUGAR_FREE=yes -declare -r I_NEED_THE_BUZZ=no +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">declare</font></b> -r <font color="#009900">SUGAR_FREE</font><font color="#990000">=</font>yes +<b><font color="#0000FF">declare</font></b> -r <font color="#009900">I_NEED_THE_BUZZ</font><font color="#990000">=</font>no -buy_soda () { - local -r sugar_free=$1 +<b><font color="#000000">buy_soda ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">sugar_free</font><font color="#990000">=</font><font color="#009900">$1</font> - if [[ $sugar_free == yes ]]; then - echo 'Diet Dr. Pepper' - else - echo 'Pepsi Coke' - fi + <b><font color="#0000FF">if</font></b> <font color="#990000">[[</font> <font color="#009900">$sugar_free</font> <font color="#990000">==</font> yes <font color="#990000">]];</font> <b><font color="#0000FF">then</font></b> + echo <font color="#FF0000">'Diet Dr. Pepper'</font> + <b><font color="#0000FF">else</font></b> + echo <font color="#FF0000">'Pepsi Coke'</font> + <b><font color="#0000FF">fi</font></b> } -buy_soda $I_NEED_THE_BUZZ +buy_soda <font color="#009900">$I_NEED_THE_BUZZ</font> </pre> <br /> <h3 style='display: inline'>Non-evil alternative to variable assignments via eval</h3><br /> <br /> <span>Google is in the opinion that eval should be avoided. I think so too. They list these examples in their guide:</span><br /> <br /> -<pre> -# What does this set? -# Did it succeed? In part or whole? -eval $(set_my_variables) - -# What happens if one of the returned values has a space in it? -variable="$(eval some_function)" +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900"># What does this set?</font></i> +<i><font color="#9A1900"># Did it succeed? In part or whole?</font></i> +<b><font color="#0000FF">eval</font></b> <font color="#009900">$(set_my_variables)</font> +<i><font color="#9A1900"># What happens if one of the returned values has a space in it?</font></i> +<font color="#009900">variable</font><font color="#990000">=</font><font color="#FF0000">"$(eval some_function)"</font> </pre> <br /> <span>However, if I want to read variables from another file, I don't have to use eval here. I only have to source the file:</span><br /> @@ -8273,36 +8304,39 @@ Hello paul, it is Sat 15 May 19:21:12 BST 2021 <br /> <span>When I do list processing in Bash, I prefer to use pipes. You can chain them through Bash functions as well, which is pretty neat. Usually, my list processing scripts are of a structure like this:</span><br /> <br /> -<pre> -filter_lines () { - echo 'Start filtering lines in a fancy way!' >&2 - grep ... | sed .... +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">filter_lines ()</font></b> { + echo <font color="#FF0000">'Start filtering lines in a fancy way!'</font> <font color="#990000">>&</font><font color="#993399">2</font> + grep <font color="#990000">...</font> <font color="#990000">|</font> sed <font color="#990000">....</font> } -process_lines () { - echo 'Start processing line by line!' >&2 - while read -r line; do - ... do something and produce a result... - echo "$result" - done +<b><font color="#000000">process_lines ()</font></b> { + echo <font color="#FF0000">'Start processing line by line!'</font> <font color="#990000">>&</font><font color="#993399">2</font> + <b><font color="#0000FF">while</font></b> <b><font color="#0000FF">read</font></b> -r line<font color="#990000">;</font> <b><font color="#0000FF">do</font></b> + <font color="#990000">...</font> <b><font color="#0000FF">do</font></b> something and produce a result<font color="#990000">...</font> + echo <font color="#FF0000">"$result"</font> + <b><font color="#0000FF">done</font></b> } -# Do some post-processing of the data -postprocess_lines () { - echo 'Start removing duplicates!' >&2 +<i><font color="#9A1900"># Do some post-processing of the data</font></i> +<b><font color="#000000">postprocess_lines ()</font></b> { + echo <font color="#FF0000">'Start removing duplicates!'</font> <font color="#990000">>&</font><font color="#993399">2</font> sort -u } -genreate_report () { - echo 'My boss wants to have a report!' >&2 - tee outfile.txt - wc -l outfile.txt +<b><font color="#000000">genreate_report ()</font></b> { + echo <font color="#FF0000">'My boss wants to have a report!'</font> <font color="#990000">>&</font><font color="#993399">2</font> + tee outfile<font color="#990000">.</font>txt + wc -l outfile<font color="#990000">.</font>txt } -main () { - filter_lines | - process_lines | - postprocess_lines | +<b><font color="#000000">main ()</font></b> { + filter_lines <font color="#990000">|</font> + process_lines <font color="#990000">|</font> + postprocess_lines <font color="#990000">|</font> generate_report } @@ -8317,35 +8351,47 @@ main <br /> <span>The solution is to use of the "assign-then-shift"-method, which goes like this: "local -r var1=$1; shift; local -r var2=$1; shift". The idea is that you only use "$1" to assign function arguments to named (better readable) local function variables. You will never have to bother about "$2" or above. That is very useful when you constantly refactor your code and remove or add function arguments. It's something that I picked up from a colleague (a pure Bash wizard) some time ago:</span><br /> <br /> -<pre> -some_function () { - local -r param_foo="$1"; shift - local -r param_baz="$1"; shift - local -r param_bay="$1"; shift - ... +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">some_function ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_foo</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_baz</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_bay</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + + <i><font color="#9A1900"># ...</font></i> } </pre> <br /> <span>Want to add a param_baz? Just do this:</span><br /> <br /> -<pre> -some_function () { - local -r param_foo="$1"; shift - local -r param_bar="$1"; shift - local -r param_baz="$1"; shift - local -r param_bay="$1"; shift - ... +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">some_function ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_foo</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_bar</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_baz</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_bay</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + + <i><font color="#9A1900"># ...</font></i> } </pre> <br /> <span>Want to remove param_foo? Nothing easier than that:</span><br /> <br /> -<pre> -some_function () { - local -r param_bar="$1"; shift - local -r param_baz="$1"; shift - local -r param_bay="$1"; shift - ... +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#000000">some_function ()</font></b> { + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_bar</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_baz</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + <b><font color="#0000FF">local</font></b> -r <font color="#009900">param_bay</font><font color="#990000">=</font><font color="#FF0000">"$1"</font><font color="#990000">;</font> <b><font color="#0000FF">shift</font></b> + + <i><font color="#9A1900"># ...</font></i> } </pre> <br /> @@ -8355,34 +8401,40 @@ some_function () { <br /> <span>I call this the paranoid mode. The Bash will stop executing when a command exits with a status not equal to 0:</span><br /> <br /> -<pre> -set -e -grep -q foo <<< bar +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">set</font></b> -e +grep -q foo <font color="#990000"><<<</font> bar echo Jo </pre> <br /> <span>Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to run in paranoid mode purely, so there must be a way to add exceptions. Critical Bash scripts of mine tend to look like this:</span><br /> <br /> -<pre> -#!/usr/bin/env bash +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><i><font color="#9A1900">#!/usr/bin/env bash</font></i> -set -e +<b><font color="#0000FF">set</font></b> -e -some_function () { - .. some critical code - ... +<b><font color="#000000">some_function ()</font></b> { + <i><font color="#9A1900"># .. some critical code</font></i> + <i><font color="#9A1900"># ...</font></i> - set +e - # Grep might fail, but that's OK now - grep .... - local -i ec=$? - set -e + <b><font color="#0000FF">set</font></b> <font color="#990000">+</font>e + <i><font color="#9A1900"># Grep might fail, but that's OK now</font></i> + grep <font color="#990000">....</font> + <b><font color="#0000FF">local</font></b> -i <font color="#009900">ec</font><font color="#990000">=</font><font color="#009900">$?</font> + <b><font color="#0000FF">set</font></b> -e - .. critical code continues ... - if [[ $ec -ne 0 ]]; then - ... - fi - ... + <i><font color="#9A1900"># .. critical code continues ...</font></i> + <b><font color="#0000FF">if</font></b> <font color="#990000">[[</font> <font color="#009900">$ec</font> -ne <font color="#993399">0</font> <font color="#990000">]];</font> <b><font color="#0000FF">then</font></b> + <font color="#990000">:</font> <i><font color="#9A1900"># ...</font></i> + <b><font color="#0000FF">fi</font></b> + <i><font color="#9A1900"># ...</font></i> } </pre> <br /> @@ -8394,27 +8446,36 @@ some_function () { <br /> <span>The following looks like a valid Bash code:</span><br /> <br /> -<pre> -if [[ "${my_var}" > 3 ]]; then - # True for 4, false for 22. +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">if</font></b> <font color="#990000">[[</font> <font color="#FF0000">"${my_var}"</font> <font color="#990000">></font> <font color="#993399">3</font> <font color="#990000">]];</font> <b><font color="#0000FF">then</font></b> + <i><font color="#9A1900"># True for 4, false for 22.</font></i> do_something -fi +<b><font color="#0000FF">fi</font></b> </pre> <br /> <span>... but it is probably an unintended lexicographical comparison. A correct way would be:</span><br /> <br /> -<pre> -if (( my_var > 3 )); then +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">if</font></b> <font color="#990000">((</font> my_var <font color="#990000">></font> <font color="#993399">3</font> <font color="#990000">));</font> <b><font color="#0000FF">then</font></b> do_something -fi +<b><font color="#0000FF">fi</font></b> </pre> <br /> <span>or</span><br /> <br /> -<pre> -if [[ "${my_var}" -gt 3 ]]; then +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">if</font></b> <font color="#990000">[[</font> <font color="#FF0000">"${my_var}"</font> -gt <font color="#993399">3</font> <font color="#990000">]];</font> <b><font color="#0000FF">then</font></b> do_something -fi +<b><font color="#0000FF">fi</font></b> </pre> <br /> <h3 style='display: inline'>PIPESTATUS</h3><br /> @@ -8423,24 +8484,30 @@ fi <br /> <span>The PIPESTATUS variable in Bash allows checking of the return code from all parts of a pipe. If it's only necessary to check the success or failure of the whole pipe, then the following is acceptable:</span><br /> <br /> -<pre> -tar -cf - ./* | ( cd "${dir}" && tar -xf - ) -if (( PIPESTATUS[0] != 0 || PIPESTATUS[1] != 0 )); then - echo "Unable to tar files to ${dir}" >&2 -fi +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre>tar -cf - <font color="#990000">./*</font> <font color="#990000">|</font> <font color="#990000">(</font> cd <font color="#FF0000">"${dir}"</font> <font color="#990000">&&</font> tar -xf - <font color="#990000">)</font> +<b><font color="#0000FF">if</font></b> <font color="#990000">((</font> PIPESTATUS<font color="#990000">[</font><font color="#993399">0</font><font color="#990000">]</font> <font color="#990000">!=</font> <font color="#993399">0</font> <font color="#990000">||</font> PIPESTATUS<font color="#990000">[</font><font color="#993399">1</font><font color="#990000">]</font> <font color="#990000">!=</font> <font color="#993399">0</font> <font color="#990000">));</font> <b><font color="#0000FF">then</font></b> + echo <font color="#FF0000">"Unable to tar files to ${dir}"</font> <font color="#990000">>&</font><font color="#993399">2</font> +<b><font color="#0000FF">fi</font></b> </pre> <br /> <span>However, as PIPESTATUS will be overwritten as soon as you do any other command, if you need to act differently on errors based on where it happened in the pipe, you'll need to assign PIPESTATUS to another variable immediately after running the command (don't forget that [ is a command and will wipe out PIPESTATUS).</span><br /> <br /> -<pre> -tar -cf - ./* | ( cd "${DIR}" && tar -xf - ) -return_codes=( "${PIPESTATUS[@]}" ) -if (( return_codes[0] != 0 )); then +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre>tar -cf - <font color="#990000">./*</font> <font color="#990000">|</font> <font color="#990000">(</font> cd <font color="#FF0000">"${DIR}"</font> <font color="#990000">&&</font> tar -xf - <font color="#990000">)</font> +<font color="#009900">return_codes</font><font color="#990000">=(</font> <font color="#FF0000">"${PIPESTATUS[@]}"</font> <font color="#990000">)</font> +<b><font color="#0000FF">if</font></b> <font color="#990000">((</font> return_codes<font color="#990000">[</font><font color="#993399">0</font><font color="#990000">]</font> <font color="#990000">!=</font> <font color="#993399">0</font> <font color="#990000">));</font> <b><font color="#0000FF">then</font></b> do_something -fi -if (( return_codes[1] != 0 )); then +<b><font color="#0000FF">fi</font></b> +<b><font color="#0000FF">if</font></b> <font color="#990000">((</font> return_codes<font color="#990000">[</font><font color="#993399">1</font><font color="#990000">]</font> <font color="#990000">!=</font> <font color="#993399">0</font> <font color="#990000">));</font> <b><font color="#0000FF">then</font></b> do_something_else -fi +<b><font color="#0000FF">fi</font></b> </pre> <br /> <h2 style='display: inline'>Use common sense and BE CONSISTENT.</h2><br /> @@ -1,6 +1,6 @@ # foo.zone -> This site was generated at 2023-12-10T11:46:05+02:00 by `Gemtexter` +> This site was generated at 2023-12-10T17:11:56+02:00 by `Gemtexter` ``` |\---/| diff --git a/uptime-stats.gmi b/uptime-stats.gmi index 51ed9fd3..1fb5c186 100644 --- a/uptime-stats.gmi +++ b/uptime-stats.gmi @@ -1,6 +1,6 @@ # My machine uptime stats -> This site was last updated at 2023-12-10T11:46:05+02:00 +> This site was last updated at 2023-12-10T17:11:56+02:00 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine. |