Ahh, you are putting the whole script _IN_ the config file?
I think what Dominik meant was the return value needs to stay under 1022, maybe I'm
wrong, can someone clarify?
The way I do it it to keep a script dir in my path and call them like this:
PipeRead "addExecutableOnMenu BrowserPopup opera galeon konqueror mozilla netscape
cnetscape"
Where addExecutableOnMenu is it's normal readable self sitting somewhere in
~/somewhere:
#!/bin/bash
#
#
MENU="$1"
shift
while [ "$1" != "" ]; do
which $1 2> /dev/null | {
read fullpath
if [ "$?" = "0" ]
then
echo "AddToMenu $MENU $1 Exec $fullpath"
fi
}
shift
done
So if I have a script over 1024 it will fail even if it's sitting in an external file?
<snip>
> I would vote in favor of an increase. It's easy for a PipeRead script to
> grow quickly, when you consider Bourne looping and branching constructs (for,
> if, case), all of which count toward the limit. There's a PipeRead in the
> distribution (system.fvwm2rc-sample-95) that exceeds 500 bytes before
> parameter expansion. The "for i in ... ; do" statement alone is over 230
> bytes. Once I saw that sample, I jumped to the conclusion that arbitrarily
> long PipeReads were not only supported, but tacitly recommended.
>
> Admittedly, a contributing factor is my coding style - I prefer longer shell
> variable names and newlines with indentation, all of which count toward the
> limit (and certainly can be trimmed).
>
> Perhaps the size limit should be mentioned in the man page (or did I miss
> it?).
<snip>
k a k @ c i s c o . c o m
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
