On Wed, Feb 27, 2002 at 12:43:29AM +0000, Mikhael Goikhman wrote: > 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 did not say that other commands *can* not have a return code but that they *do* not have one. My intentions was to keep the return code of conditionals separate from normal return codes. The cond_rc function argument can easily be replaced with a return structure that can store multiple types of return codes. We shouldn't mix both because it would become hard to understand for example Current (foobar) Read <file> returns (the rc of Read or the rc of Current?). > 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. Yes, it would be nice if return codes work in scripts too. > About names. Maybe to use "CondStatus" or generally "Status", not "Cond". > (Like some shells have $status that is another name for $? return code.) First, I think that the names I chose are brain dead. The reason for "Cond" is to indicate that it uses the return code of CONDitional commands. Otherwise I'd simply have used "Else". "CondCase" resembles the "switch/case" in C where you can check against many values in a single call. > 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. It's not necessary if we keep the return code of conditionals separate from other return codes. > 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. Can you give me an example? > 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. I should rather have said that the behaviour outside a function is undefined. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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]
