On Mon, Jun 26, 2006 at 01:50:30PM +1000, Scott Smedley wrote: > > Hi Dominik, > > > That's just one purpose of the command. I was always fond of the > > idea to prototype or even implement modules as shell scripts. > > Yes, that would be cool. IMHO, I think it would be prudent to create > "bashlib" (akin to perllib), instead of adding ModuleListenOnly command.
Well, the new command is not a big deal. I just needed to add some code to close the fvwm_to_app pipes and modify some places to handle the situation that there is no fvwm_to_app pipe. To comment on the "bashlib" (which would be unusable for me, as I never use shells that are not either POSIX /bin/sh-compatible or zsh ;-) (Unless force to, of course): I don't have any idea how you could detect the size and byte order of a long (which is the base data type of a module message) from inside a shell script. Well, maybe fvwm could provide this information through the module's environment. > But I suppose that should be a 2.6 feature? Um, you probably meant "a post-2.6 feature"? Yes, I think so, assuming that 2.6 would be released at a not too distant point in time. > > It is certainly possible to handle input > > from fvwm to the module in the script itself, but hard to > > guarantee that the input is processed in a timely fashion > > Why is that? Because shells were not made to handle input in that way. Look at my script for example. It would need two external triggers for its operations: * input from the fvwm pipe * a certain period of time has passed. Well, with zsh there is zselect that can trigger on both events at the same time (works like select()), but other than that I'd have to make something up with reading the fvwm pipe in a subshell (because it blocks the shell). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
