Happy with my bash progress!
-
Look up "shellcheck", find a plugin for your editor. It should help a lot.
-
Oh goodness, this looks incredibly useful. Thank you!
-
I'm with them, one line is for showing off, not utility.
Utility has comments!
-
This is excellent advice. Bash is fantastic but it has a lot of "foot guns" that can cause problems. Especially where spaces are concerned...
Op: good job with the script
-
I have studiously avoided learning any bash scripting for the 17 years I've used Linux, so all I can say is good job! Actually just today I found a command that I needed to get a certain appimage to run without crashing, and I remembered enough that I was able to make it into a script (I struggle with whether it's !# or #!). Having just done it today, I can confirm you don't need to include '/bin/bash', just FYI. I believe that is assumed.
-
It makes it usable without typing bash. Same would apply for a python script. For example you can make a python script named with no extension and add #!/usr/bin/python to the top of the file. Bash shell sees this and knows to execute the script using that python path.
Then you just include the directory in your $PATH and chmod +x the script. Then you can type $python_script instead of $python python_script.py
-
findis super arcane; most people don't know how to use it. Congrats!(a note for the future with all programming, be careful of numbers with leading zeros, they might indicate base-8, causing your program to fail on 09)
-
Interesting. This particular script I'm just double clicking to run, but I did name it script.sh. If I were to run it in the terminal, I would just do ./script.sh
-
Good job! Flexible tools empower us. Keep it up and spread the love with other people!
-
Yes. You're correct. The script will execute with /bin/bash by default. However, #!/bin/bash is still a good habit to have. Some platforms may be running an "sh" shell by default. In this case if you ran the script it would execute with /bin/sh instead. Which would work or not work depending on if your script was written in purely sh syntax and not using any uniquely bash style syntax.
Bash can run all sh scripts but sh cannot run all bash scripts. So explicitly stating for which one your script was written for is good practice to not run into errors if you move your script to a different environment.
-
Good job. But don't worry if you have to look up answers. I've been at this for 20 years and I still have to look up and double-check basic syntax like the classic
find -execone. No big deal if only takes a couple of seconds.This is definitely the sort of thing that LLM AI tools can help with, in theory.
-
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
