According to POSIX, variables that contain lower-case letters are for application use. If Debian (or whoever) introduces such variable names, they are being nonconforming.
For instance, my programs might be in /home/kaz/bin. Suppose I create a one-letter variable:
k=/home/kaz/bin
Then /home/kaz/bin/foo can be run as
$k/foo
Bash will complete on this. Firstly, $k[Tab] will add the missing slash to make $k/. Then if Tab is hit twice, the completions under /home/kaz/bin are shown.
Since k contains an absolute path, it does not rely on PATH searching.
The programs under $k/ can refer to each other using the $k/ notation, without relying on PATH.
The comma notation relies on PATH. When the ,foo script wants to invoke the ,bar script and just calls it ,bar args ... that relies on PATH containing the directory in which ,bar lives.
For interactive use, I'd use PATH anyway: put /home/kaz/bin at the end. Then if the system shadows one of my programs prog, I can just use ~/utils/prog or $k/prog to detour around the clashing system program. My programs themselves don't rely on PATH for calling each other, so they are immune to the shadowing, and since I added the new PATH element at the end, I haven't perpetrated any shadowing that would break system programs.
For instance, my programs might be in /home/kaz/bin. Suppose I create a one-letter variable:
Then /home/kaz/bin/foo can be run as Bash will complete on this. Firstly, $k[Tab] will add the missing slash to make $k/. Then if Tab is hit twice, the completions under /home/kaz/bin are shown.Since k contains an absolute path, it does not rely on PATH searching.
The programs under $k/ can refer to each other using the $k/ notation, without relying on PATH.
The comma notation relies on PATH. When the ,foo script wants to invoke the ,bar script and just calls it ,bar args ... that relies on PATH containing the directory in which ,bar lives.
For interactive use, I'd use PATH anyway: put /home/kaz/bin at the end. Then if the system shadows one of my programs prog, I can just use ~/utils/prog or $k/prog to detour around the clashing system program. My programs themselves don't rely on PATH for calling each other, so they are immune to the shadowing, and since I added the new PATH element at the end, I haven't perpetrated any shadowing that would break system programs.