I’ve been homelabbing for a few years now, and recently I’ve really been focusing in on learning how to use gnu/linux. I thought it might be fun to periodically share the things I’ve been learning. The stand outs for me this past week were:
- Use the full path when referencing files and directories in bash scripts (Edit: when it makes sense, which is something I’m also still learning. This mkaes sense when the files will always be located in the same place.)
- In a bash script, the variable
${file##*/}will get you the name of the file your script is handling (example, when looping over files in a directory. I believe that’s a shell/bash standard variable, but I need to learn where it came from and how it works) - Ubuntu gets a ton of justifiable criticism, but I find Canonical’s Multipass to be a great tool for spinning up Linux virtual machines. Especially on Apple silicon macs.
- Piping the output of
lstogrepas a variable in a path is a great way to change to a directory you know exists but can’t remember the exact name of. (Example:cd ~/movies/“$(ls ~/movies | grep movie-name)”) - The reason Mac cli utilities have syntax variations compared to the standard gnu/linux utilities is because macOS and its cli utilities are BSD based. This was information I knew at a high level, but had never really understood the implications of until this week.
- Related to point 5, if you’re on macOS trying to learn and you’re annoyed by the syntax differences between bsd and gnu utilities, you can run this script from darksonic37 on github to remove the bsd utilities from macOS and replace them with their gnu counterparts. (I have not run or reviewed the script. I found mulitpass first, and so far I’m happy using the Ubuntu virtual machine)
It’s definitely an edge case by say you’re in ~/ and you run a script like ./code/script.sh then it thinks the current working direct is ~/ rather than what is probably intended which is ~/code/. If your bash script uses full paths like /home/$USER/code/ then it will still run correctly regardless of the current working directory that the scrip was run from.
To insure the script works on the files you want it to work on.
If you use a relative path in a script (is relative the right word?), with something like:
mv *.txt /place/to/move/to/The script will act on the files in the current working directory, which may not be the files you intend for the script to act on.
If you put the absolute path to where the files reside in the filesystem, then you can run the script from any location, and know that it will act on the files in the specified directory.
Maybe always is too strong a statement. For the scripts I was working on, it was a learning moment when I ran the script without the full path and the script errored out because the files were not in the working (home) directory. (I had ssh’d into the machine to run the script)
I’d never use absolute paths unless it is a file that will always be there, e.g. system files, icons, etc.
That’s fair. Always was probably too strong.