summaryrefslogtreecommitdiff
path: root/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2021-05-23 20:50:02 +0100
committerPaul Buetow <paul@buetow.org>2021-05-23 20:50:02 +0100
commit58e0d8982f65f01d8c4797484d847a7f0331ec6a (patch)
treede1d21bc3b72a16513a6cf1e64e038689e3f2d46 /gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi
parent96d66dfa82250248dd2481ad1537244aaee2d6c5 (diff)
fix
Diffstat (limited to 'gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi')
-rw-r--r--gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi4
1 files changed, 2 insertions, 2 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 b4fabbff..d7f39800 100644
--- a/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi
+++ b/gemfeed/2021-05-16-personal-bash-coding-style-guide.gmi
@@ -41,7 +41,7 @@ as the shebang line, but that does not work on all Unix and Unix-like operating
I know there have been many tab- and soft-tab wars on this planet. Google recommends using two space soft-tabs for Bash scripts.
-I don't care if I use 2 or 4 space indentations. I agree, however, that we should not use tabs. I tend to use four-space soft-tabs as that's how I currently configured Vim for any programming language. What matters most, though, is consistency within the same script/project.
+I don't care if I use two or four space indentations. I agree, however, that we should not use tabs. I tend to use four-space soft-tabs as that's how I currently configured Vim for any programming language. What matters most, though, is consistency within the same script/project.
Google also recommends limiting the line length to 80 characters. For some people, that seems to be an old habit from the '80s, where all computer terminals couldn't display longer lines. But I think that the 80 character mark is still a good practice, at least for shell scripts. For example, I am often writing code on a Microsoft Go Tablet PC (running Linux, of course), and it comes in convenient if the lines are not too long due to the relatively small display on the device.
@@ -118,7 +118,7 @@ addition="$(expr "${X}" + "${Y}")"
substitution="$(echo "${string}" | sed -e 's/^foo/bar/')"
```
-I can't entirely agree partially here. The external commands (especially sed) are much more sophisticated and powerful than the Bash built-in 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).
+I can't entirely agree here. The external commands (especially sed) are much more sophisticated and powerful than the Bash built-in 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).
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. However, there is 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 relatively obscure here (even Perl will be more readable then - Side note: I love Perl).