Tips for working with shell scripts
Tags: beginners, linux, script, git
Published: 2019-04-12 15:35:09

---
title: Tips for working with shell scripts
published: true
tags: beginner,linux,script,git
canonical_url: https://medium.com/@pemtajo/tips-for-working-with-bash-scripts-ff85c0420ac7
---

Years ago I was programming for a small company who worked with _boarded system_. There I wrote codes for _shell scripts_, _python scripts_ and another codes for _boarded systems_, sometimes for clients who lived in another state with machines that I don’t had any access, so my scripts were always a _black box_ and for that was very common send the updates for e-mail.

![Alt Text](https://media.giphy.com/media/nkLB4Gp8H6hFe/giphy.gif)

Therefor, the client sended me a e-mail with the subject: “Not working”. In 5 minutes I refreshed the file and sended back. Problem solved right? Not totally.

It’s hard to small companies, even freelancers, do a good logistic to work with bash scripts because the client do not can wait and you have to do something to solve the problem, so the “add this line” always win against a robust process.

After a lot of problems, with developer and freelancer, I want to share good advices for work with _sh files_ (maybe can be usefull for another scripts)

It’s simple tips, but the bugs (and headache) is in the details:

#### Write all in functions (isolated if possible)

Do your logic fragmented, will help when need change and recicly your code.

Do a scope for each function support you to change the logic without bugs.

#### Always pick the file on the master

It’s obvious, I know, but in real world, change your file for send to your client without commit before is faster, and in a busy day, you can forget to do this commit later, so you have one file in your git and another with your client. It’s not hard to imagine catastrophics scenarios.

#### Always create branchs for work

That tip is usually for teams, but work well for freela too and helps to do not commit direct in master as well as avoid bugs without revision and “commit for commit”.

#### Comment on shell script

It’s an eternal discussion about comment your code or not, in other languages I believe is not necessary, but how in _bash_ sometimes is not intuitive, like I’m a practical developer, I prefer comment my _bash scripts_, in the end this save my time.

#### Do tests

Yes, do test in bash scripts.


![Alt Text](https://media.giphy.com/media/3o6Mbbs879ozZ9Yic0/giphy.gif)

This tests don’t need be a unit test, but can be a functional tests, for example.  
If your script move a file to another folder, you can:

1. create a file in the original folder
2. run script
3. do assert that file is in the destiny folder, and not in the origin

With tests, is easy to see fool mistakes. Do the test in bash is hard sometimes, so use another language for this, Python is a good call and is my preference.

#### Do a log

And finally the golden tip. One good log, will help to identify the errors faster, and it’s usefull to see all activity and performance, like find bugs and system bottlenecks. It’s easy do log in bash files, so is not have a reason to do not do one.

This is my tips to do a process with less bugs and fatal errors.