Shell scripting is a strange beast. The fact how long it took the author to explain the reason for the first parameter expansion pretty much demonstrates that. You can (and I regularily fall for that) loose yourself in scripting. It sort of lures you in. You take some command line invokations, wrap them in a while loop or pipe it to some grep/sed/awk magic, and achieve things. You can even go and learn the idioms. Important things like "set -e" and ${foo}, remember to quote every file and directory name that contains a variable (yes, people use spaces in the project directories they upload) and yadda yadda. Now you are approaching something vaguely safe. But dont rattle it too much, it might break. And it will definitely break in 2 years. But hey, you've written a program... It feels like compiance bias. "I can learn everything necessary to make bash into a programming language", yeah, you can. However, the question is really if you should...
For us mere mortals: fff is "a simple file manager written in Bash". Here's what I learned from starting to read the source code to fff - in particular, the main function.
Won't work. This sets read's environment variable read_flags and expands the current shell's value of $read flags, which generally won't be set. For example:
a=1 echo $a
Prints nothing because a is not defined in the current shell. To fix, make read a separate statement
