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.
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:
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.
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.
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”.
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.
Yes, do test in bash scripts.
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:
- create a file in the original folder
- run script
- 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.
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.