No problem. I understand and was/am the same way.
I like to flesh out my scripts/programs; it's a force of habit. I write them to account for whatifs, based on different setups. If you were to run it, you can have no dependency checking if you wanted.
The while loop wouldn't keep loading pluma, but it would were it within the actual code block and not part of the condition, or if something in the loop didn't specify that it should break, such as the lsof check. Every second the loop checks for the file you were working on being active; if it's not found, a non-zero exit status is given, which || picks up on, and thus breaking from the loop and ending the script. It would keep loading pluma, however, if another process were using the same file; see below for oversight.
The lack of output while xed was editing the specified file was intentional; you'd see output if you stopped using the file, regarding your test. An oversight on my part though, is that I forgot you might have the file open by another process, such as a different editor; in this case, you'd want to do a bit more, but this would likely suffice, unless it's a configuration file for a program which gets frequently used.
While tests that something is true or false (boolean), and if it's either one, break from the loop, otherwise continue iterating through each command in the block. A simpler example:
Code: Select all
while true
do
echo "This is a test."
done
That would infinitely repeat the echo command, because true will always exit 0, and while is testing for success (0 exit status). The condition for breaking out of the loop is never met. Another common example:
Code: Select all
declare -i A=1
while [ $A -le 10 ]
do
echo "$A"
A+=1
done
The first line declares the variable A as an integer, allowing the use of NAME+=n to increment variable NAME by n. The condition to continue looping, is that A should be less than or equal to 10, otherwise the condition is no longer met, thus breaking from the loop.
Another approach:
Code: Select all
evince & A=$!
while ps $A &> /dev/null || break
do
:
done
I used evince as an example here -- a viewer for things like PDF documents. This will load evince, putting it into the background (it's a GUI, so you'll still be able to access it), thus allowing you to capture its PID into the A variable, which then gets tested for in the while loop. The loop's focus isn't the contents, it's the condition. For as long as ps detects the PID (&> /dev/null omits output), it'll continue checking for it, otherwise it'll break from the loop. The : is just shorthand for true, so it basically does nothing. It's a similar concept, but for a different purpose.
Hope that all helps you understand the code.
