Happy with my bash progress!
-
Yeah, you can't keep it all in your head. Knowing what to look up is the better part of the battle.
-
Quick question to this (sorry for the hijack):
I use shorthands if possible, because scripts just look cleaner with a bunch of short oneliners than with if-elses. Though there is some ambiguity in POSIX of how the shell handles some cases with them.
But i only had one case, a minimal and strictly POSIX but incomplete and abandoned shell, where some complex scripts failed; mrsh.If i do a project i want to share with the public, should i do shorthand or if-elses? What is your preference?
-
I really love bash scripting. I use it to symlink my dotfiles from my git repo, to configure my void system the way i like it, dmenu scripts, and i also use it on my laptop to send me notifications when my battery is almost empty, when i plug/unplug the charger, when it's fully charged, and to hibernate when it's lower than 5%. For some reason apps like upower don't seem to work on my laptop so bash offered a solution.
-
Shorthand is hard to learn from and hard to troubleshoot in complicated scripts.
-
I keep it to shorthand for simple if-then, but write multi-line actions or if-then-else out. It's manageable this way.
-
If you want to share your script with others, I think it's a good idea to make it as easy to read as possible.
If you're just keeping it for yourself, that's fine. But if you're sharing it with me, the more readable it is, the easier I'll be able to understand what you're trying to do and how you're solving the problem. This will make it easier for us to discuss ideas and improvements together. To be honest, one-liners can be a bit confusing because they can do multiple things at once. Breaking things down into individual steps makes it easier for me to follow along and for you to understand why you made certain decisions.
Plus, it's a good habit to get into for your own future reference - you'll be able to look back and understand your thought process more easily.
As the famous saying from SICP goes:
programs must be written for people to read, and only incidentally for machines to execute
-
@harsh3466 how cute! Happy to see you learn hehe
-
That's fantastic. I'm not using it that deeply yet. I do have other scripts for managing my media files and adding them to my server as I rip music and DVDs. I also am loving learning it and using it.
-
Agree. Make it as easy to read as possible. I learned this particularly after I had written a script that had a lot of nesting. It worked initially, but not for long and when I went back to debug I was like, "What the fuck was I thinking here?"
I ended up completely rewriting it to minimize the nesting and make it much more efficient and readable
-
I've had to learn heavy duty bashing for work, and happily did take the plunge. However, they also had me learn PHP and I'll drop this as a hook and line for OP: you can do shell-script duties with PHP also, and once you hit your head on sed enough times, I hope you remember me telling this. All that string manipulation is much nicer with PHP functions, and for running shell commands there is shell_exec().
-
Use shellcheck to test script syntax.
