2015-03-14 The Downsides of Free Food
This post was extracted from https://alexschroeder.ch/wiki/Comments_on_2014-06-23_Oddmuse_Migration
It all started like a simple bash refactoring, but look! This time was special because someone decided to post a link to google style guide and claimed that it is a "nice resource". Well... I just had to explain everything. At first, I didn't think that my answer is worth a blog post. But hey, it seems like a lot of people worship these guides... So I decided to extract it into my blog.
I suggest you not to read their guide
It is plain bullshit.
Well, I can quickly go through most of the mistakes:
for dir in ${dirs_to_cleanup}; do
Clearly $dirs_to_cleanup is not quoted, this indicates that there is something wrong. Better use array and "${dirs_to_cleanup[@]}".
Also, what is the point of using curlies like ${var} everywhere??? They'd better teach to put quotes everywhere. Such style is propagated only by Google style guide (a guide written by people who think that you're stupid enough not to understand the two exceptions when ${} is actually required, but at the same time these guys don't even know how to quote variables correctly). If that made any sense then we would be doing the same thing in perl and php, but we don't.
rm "${dir}/${ORACLE_SID}/"*
That's rm without -- . Well, not a huge issue, but that's a styleguide or what?
if [[ "$?" -ne 0 ]]; then
Funny. Left side of the expression is quoted when it does not have to be. But even if it had to be quoted, what would be the benefit to quote $? ? It is always an integer. Oh, and if it is an integer, then it would be better to use (( )) for arithmetic expressions, like: if (( $? != 0 )); then
case "${expression}" in
Does not have to be quoted, actually, but at least it does not hurt.
while read f; do
echo "file=${f}"
done < <(ls -l /tmp)
WHOA! Holy sh...!!! That's amazing... Bash pitfall #1, parsing ls, read without -r. It just couldn't be worse.
# -z (string length is zero) and -n (string length is not zero) are
# preferred over testing for an empty string
if [[ -z "${my_var}" ]]; then
do_something
fi
But hey, it is as simlpe as if [[ ! $my_var ]]; then , why would they complicate things so much?
# Instead of this as errors can occur if ${my_var} expands to a test
# flag
if [[ "${my_var}" ]]; then
do_something
fi
What??? Which error?? Am I missing something?
zip_version="$(dpkg --status zip | grep Version: | cut -d ' ' -f 2)"
A rule of thumb is that you should never pipe any of these commands together: sed, awk, grep, perl, cut and some others. The reason is that we usually need such functionality that is present in most of them, and indeed with a little trickery these tools will usually do each others' job. However, they use completely different approaches.
In this particular case you can use grep with -P flag (perl regexes! Woohoo!). Like this:
zip_version=$(dpkg --status zip | grep -Pom1 'Version: \K.*')
But there are other solutions as well.
if ! mv "${file_list}" "${dest_dir}/" ; then
Just look at that variable. It says "file list". Aha, sure, this would definitely work.
addition=$((${X} + ${Y}))
Stupidity all over the place. This should be:
((addition = X + Y))
At least that "$file_list" example will give me a good laugh for the next few days. 😂
Maybe they should stop eating their fucking free food and go through BashPitfalls instead?
Also, I feel like this post is lacking some image. Well, you can look at this image, if you wish.
2015-03-08 Bash Pitfalls
Bash is hard, but that's not an excuse.
Every time I see something like this:
- !/bin/sh
read FOLDER
[[ ! -d $FOLDER ]] && mkdir $FOLDER || printf "Directory $FOLDER already exists"
echo $myVar > $FOLDER/log
echo Please copy your files to $FOLDER
read > /dev/null # wait for Enter
sleep 1 &
wget -Out http://link.org
if [[ $num1 > $num2 ]]
then
echo 'Error!'
clear
fi
PATH=data/stuff;
cd $PATH;
sudo echo $'Script started' >> /etc/mylog
echo "Math test: 0 + 2 = ${0+2}"
rm -rf $FOLDER
I feel horrible. It is like my insides are falling out! ARGH!
But this is not getting better at all!
Is it so hard to go through the list on BashPitfalls page? I don't think so. However, most people would much rather follow retarded Google style gu-fucking-ides than learn the language they are using.
I post comments like this from time to time:
https://alexschroeder.ch/wiki/Comments_on_2014-06-23_Oddmuse_Migration
But look, this time was special because someone decided to post a link to google style guide and claimed that it is a "nice resource". I've extracted my comment into 2015-03-14 The Downsides of Free Food, please check it out.
Is there any hope?
Yes, get yourself a steel pipe.
Joking aside, lets start something interesting now! I will pick a pseudo-random open-source project every week (or at least every month) and refactor it. I will document everything on this blog. Later, if there are enough refactored projects and if this stuff becomes interesting to people, I will extract it to a separate wiki. Of course, every time I will do a pull request with all of the changes.
Although I try to make the code perfect, sometimes it is not possible to do it fully. Things for you to note:
- Sometimes it is too hard to find out the purpose of some poorly-written dumbfuscated code, I might not touch such lines. There is a high chance to break stuff in such situations, and sometimes the behavior of edge-cases will change. I think that such lines could be dealt with later, when my more obvious changes are commited.
- I don't want to spend too much time on one project, and I will not pick the same project twice. Therefore some possible changes might be left behind. Feel free to do some post-fixes yourself!
- I'm not a Bash god, you will find much more experienced people on #bash, for example. This means that I might not be capable of fixing some tricky bugs.
The goal of this project is to spread the knowledge about bash pitfalls and improve the quality of open-source projects.
Please be conscious.