On 27 Feb 2002 07:17:12 +0100, Dominik Vogt wrote: > > 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
If you agree about return codes for other commands, I am not sure having 2 kinds of return codes is needed. It is easy to invent a case when 3 kinds of return codes or more are possible. How about to have these: * one for the last conditional (3 possible values) * one for the last complext function, they may just: Return any_number * one for the last, say, Exec/PipeRead (returns system's status code) * one for the last command (including all commands above too?) * one to bring them all and in the darkness bind them... No, this is a joke, I think having one return code for all commands is ok. If conditionals are commands and not language constructs, they should behave like all other commands. But we probably should first see some real life usages to decide about this. > example > > Current (foobar) Read <file> > > returns (the rc of Read or the rc of Current?). It should return rc of Current. If someone needs to branch over Read, he should do this in a function: Current (foobar) ReadOrWrite > > 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. But then it is nice to preserve the previous status of other commands. > > 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? Any example that works with Cond does not work with CondCase for me. This is not expanding problem, just replace $0 with CondCase. AddToFunc TestCondCommand + I Next ($1) Nop + I $0 (0) Echo ($0 0) + I $0 (1) Echo ($0 1) + I $0 (-1) Echo ($0 -1) TestCondCommand Cond XTerm # nothing is echoed, ok TestCondCommand Cond _none_ # 0 and 1 are echoed, ok TestCondCommand CondCase XTerm # nothing is echoed TestCondCommand CondCase _none_ # nothing is echoed 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]
