> But perhaps some more usefull ideas could be derived from this. Use a
> sed/awk/perl command to build up a menu that has function calls and
> passing in the found filenames, for things like:
>
> - a menu of background files (and the function invokes xv on them).
> - to get all of the modes from the current version of xlock
> dynamically so you don't have to update your menu every time a new
> version comes out.
> - a list of files in a directory that you freqently edit to pop them
> up in your favorite editor (perhaps XEmacs & gnuclient to put them
> into your currently running XEmacs).
I like this idea too; it could help with a general configuration tool for
fvwm. (Kudos to the author of the "Braindead" config program)
> Rob> 2. I think there's a race condition between doing the exec
> Rob> and the read. As I recall, "exec" always background tasks, so there's
> Rob> no way to make sure its done before doing the read.
>
> Ah. Hadn't thought about that...
>
> I wonder how difficult it would be to implement a solution to that.
> Like an Exec variant that puts it into the background so we don't lock
> up fvwm, but monitors the child to see if it's still alive and have a
> Wait variant that waits for the last Exec'd child to finish. I'll
> have to look into something like that.
Does fvwm block on a fifo read? Wouldn't writing the output to a fifo and
have fvwm read from that fifo do the trick? You'd probably have to write
a simple little launch program to check that fvwm is currently reading
from the fifo before letting you're real "script" pump output into it.
Comments?
--
Dan Miner dminer_at_nyx.cs.du.edu
"The longer I stare at this screen; the blanker it gets."
Linux: try it, you'll like.
"Your program is encoded in pi." I started with a 64
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Dec 14 1995 - 23:58:04 GMT