On 24 Feb 2002 01:42:09 +0100, Dominik Vogt wrote: > > [SNIP, see mailing list archive for more details] > > I've made a shot at the "if-else" syntax. Now, all conditional > commands (and only conditional commands) have a return code that > can be true (1), false (0) or error (-1). There are three new > conditional commands: > > Cond (returncode) command > CondCase (returncode) command > > These two execute the command only if the last conditional > command returned the given return code. > [...] > > Return codes are only defined inside complex functions and are not > passed to sub functions or vice versa. There is also a new > variable $[cond.rc] that is expanded to the last return code. > This is invalid outside complex functions or in conditional > commands. The code is not well tested yet but complete. I've no > problem to change it again if we can think of something better. > Now that the funtion arguments allow to pass a return code it is > easy to make changes. If you want to play with it, be sure to > read the new parts of the man page (commands and CONDITIONAL > COMMANDS section).
This is a good solution to the if-else problem. However I may remind that my latest patch did a bit more. I feel that this extra functionality could be useful, although more thoughts may be needed. Every command not only conditionals could return status code (0 or Success by default). For example, Read (NoFile) and ModuleSynchronous (Timeout). I don't think limiting return codes to commands inside functions is required (it is easier to implement, yes). This may be solved together with "+" command validity by keeping some global data (in Scr) for every pipe separately. I.e. last_added_item and rc should be local. About names. Maybe to use "CondStatus" or generally "Status", not "Cond". (Like some shells have $status that is another name for $? return code.) Also I suggest a command "Preserve" that preserves the previous status. I.e. your "CondCase (NoMatch)" could be "Preserve Status (NoMatch)". This Preserve command is useful by itself, not only before Status command. Status names should not be boolean names. "Match", "NoMatch", "Error". Numbers are also ok, but "true" or "off" are not too much informative. CondCase does not currently work. Also $[cond.rc] outside of functions may be expanded to 0, not to itself, but this is not important if "if-else" is limitted to functions only. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
