See: https://sourceforge.net/tracker/index.php?func=detail&aid=1335255&group_id=35398&atid=413960 Basically If you run this at the bash prompt (this is independent of anything in fluxbox-generate_menu (FBGM)): bash ~ $ find_it () { which $1 > /dev/null 2>&1 && shift && $*; } bash ~ $ normal_find () { while [ "$1" ]; do find_it $1 echo "[exec] ($1) {$1}"; shift; done; } bash ~ $ normal_find firefox c (firefox) {firefox} it should have displayed "[exec] (firefox) {firefox}". A trivial fix is to do this: bash ~ $ normal_find () { while [ "$1" ]; do find_it $1 echo "[exec ] ($1) {$1}"; shift; done; } That is put a space between the "c" and the "]". Then I get: bash ~ $ normal_find firefox [exec ] (firefox) {firefox} This is ok for fluxbox, it doesn't care about whitespace but it needs the "[exec]" or the submenu's won't work properly in the generated ~/.fluxbox/menu file.
I've figured out the problem in a little bit more detail. In my home directory I have a directory called "c". For some reason in that echo statement, echo "[exec]..." it is globbing [exec] into a set that looks for the characters "e", "x", or "c" in the path. Since the directory "c" is in the path (my home directory) it outputs "c" since it was found. Now for any bash gurus out there, why is it doing this? I mean the command: echo * displays everything in the `pwd` but the command echo "*" displays '*' so why is that echo globbing "[exec]" into [exec]?
Here's a possible fix: find_it () { which $1 > /dev/null 2>&1 && shift && "$@"; } note the "$*" changed to ""$@"" and keep the same normal_find function: normal_find () { while [ "$1" ]; do find_it $1 echo "[exec] ($1) {$1}"; shift; done; } now "normal_find firefox" gives: [exec] (firefox) {firefox} that $* needs to be changed to "$@" everywhere that echo line exists in the fluxbox-generate_menu command. This is just one possible way to correct this.
Created attachment 71256 [details] fix for fluxbox-generate_menu described in comment #2 fix for fluxbox-generate_menu described in comment #2
Fixed upstream r4129. I don't think this one needs a bump, but if anything else crops up before the next release I'll include this one too.
Yeah I think the bug at sf.net is being moved upstream also, thanks.
