diff options
| author | Paul Buetow <git@mx.buetow.org> | 2021-05-16 11:40:07 +0100 |
|---|---|---|
| committer | Paul Buetow <git@mx.buetow.org> | 2021-05-21 05:11:05 +0100 |
| commit | cae4c7372929f0b386cb88f3a31cfe44c01863d6 (patch) | |
| tree | d782dcf9b04dbeae9b5deda909bba92284017c28 | |
| parent | 6ea4ed23d500e6281a2ddb282cf24e65c75ee1a8 (diff) | |
some mods
| -rw-r--r-- | content/html/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.html | 11 | ||||
| -rw-r--r-- | content/md/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.md | 11 |
2 files changed, 14 insertions, 8 deletions
diff --git a/content/html/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.html b/content/html/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.html index 20411ade..08084175 100644 --- a/content/html/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.html +++ b/content/html/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.html @@ -131,7 +131,7 @@ addition="$(expr "${X}" + "${Y}")" substitution="$(echo "${string}" | sed -e 's/^foo/bar/')" </pre> <p>I don't agree fully here. The external commands (especially sed) are much more sophisticated and powerful than the Bash builtin versions. Sed can do much more than the Bash can ever do with native capabilities when it comes to text editing (the name "sed" stands for streaming editor after all).</p> -<p>I prefer to do light text processing with the Bash builtins and more complicated text processing with external programs such as sed, grep, awk, cut and tr. There is however also the case of medium-light text processing where I would want to use external programs. That is so because I remember using them better than the Bash builtins. The Bash can get quite obscure here (even Perl will be more readable then - Side note: I love Perl).</p> +<p>I prefer to do light text processing with the Bash builtins and more complicated text processing with external programs such as sed, grep, awk, cut and tr. There is however also the case of medium-light text processing where I would want to use external programs too. That is so because I remember using them better than the Bash builtins. The Bash can get quite obscure here (even Perl will be more readable then - Side note: I love Perl).</p> <p>Also, you would like to use an external command for floating point calculation (e.g. bc) instead using the Bash builtins (worth noticing that ZSH supports builtin floating points).</p> <p>I even didn't get started what you can do with Awk (especially GNU Awk), a fully fledged programming language. Tiny Awk snippets tend to be used quite often in Shell scripts without respecting the real power of Awk. But if you did everything in Perl or Awk or another scripting language, then it wouldn't be a Bash script anymore, wouldn't it? ;-)</p> <h2>My additions</h2> @@ -186,7 +186,7 @@ END % bash -c 'source <(./vars.sh); echo "Hello $user, it is $date"' Hello paul, it is Sat 15 May 19:21:12 BST 2021 </pre> -<p>When downside is that ShellCheck won't be able to follow the dynamic sourcing anymore.</p> +<p>The downside is that ShellCheck won't be able to follow the dynamic sourcing anymore.</p> <h3>Prefer pipes over arrays for list processing</h3> <p>When I do list processing in Bash, I prefer to use pipes. You can chain then through Bash functions as well which is pretty neat. Usually my list processing scripts are of a structure similar to the following example:</p> <pre> @@ -263,7 +263,7 @@ set -e grep -q foo <<< bar echo Jo </pre> -<p>Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to purely run in paranoid mode so there must be a way to add exceptions. Critical bash scripts of mine tend to look like this:</p> +<p>Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to purely run in paranoid mode so there must be a way to add exceptions. Critical Bash scripts of mine tend to look like this:</p> <pre> #!/bin/bash @@ -271,11 +271,14 @@ set -e some_function () { .. some critical code + ... + set +e # Grep might fail, but that's OK now grep .... - local ec=$? + local -i ec=$? set -e + .. critical code continues ... if [[ $ec -ne 0 ]]; then ... diff --git a/content/md/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.md b/content/md/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.md index 61361c84..10d266fb 100644 --- a/content/md/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.md +++ b/content/md/gemfeed/2021-05-15-personal-bash-coding-style-guide.draft.md @@ -106,7 +106,7 @@ substitution="$(echo "${string}" | sed -e 's/^foo/bar/')" I don't agree fully here. The external commands (especially sed) are much more sophisticated and powerful than the Bash builtin versions. Sed can do much more than the Bash can ever do with native capabilities when it comes to text editing (the name "sed" stands for streaming editor after all). -I prefer to do light text processing with the Bash builtins and more complicated text processing with external programs such as sed, grep, awk, cut and tr. There is however also the case of medium-light text processing where I would want to use external programs. That is so because I remember using them better than the Bash builtins. The Bash can get quite obscure here (even Perl will be more readable then - Side note: I love Perl). +I prefer to do light text processing with the Bash builtins and more complicated text processing with external programs such as sed, grep, awk, cut and tr. There is however also the case of medium-light text processing where I would want to use external programs too. That is so because I remember using them better than the Bash builtins. The Bash can get quite obscure here (even Perl will be more readable then - Side note: I love Perl). Also, you would like to use an external command for floating point calculation (e.g. bc) instead using the Bash builtins (worth noticing that ZSH supports builtin floating points). @@ -175,7 +175,7 @@ END Hello paul, it is Sat 15 May 19:21:12 BST 2021 ``` -When downside is that ShellCheck won't be able to follow the dynamic sourcing anymore. +The downside is that ShellCheck won't be able to follow the dynamic sourcing anymore. ### Prefer pipes over arrays for list processing @@ -269,7 +269,7 @@ grep -q foo <<< bar echo Jo ``` -Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to purely run in paranoid mode so there must be a way to add exceptions. Critical bash scripts of mine tend to look like this: +Here 'Jo' will never be printed out as the grep didn't find any match. It's unrealistic for most scripts to purely run in paranoid mode so there must be a way to add exceptions. Critical Bash scripts of mine tend to look like this: ``` #!/bin/bash @@ -278,11 +278,14 @@ set -e some_function () { .. some critical code + ... + set +e # Grep might fail, but that's OK now grep .... - local ec=$? + local -i ec=$? set -e + .. critical code continues ... if [[ $ec -ne 0 ]]; then ... |
