On Wed, Feb 27, 2002 at 10:58:05AM +0000, Mikhael Goikhman wrote: > On 27 Feb 2002 07:17:12 +0100, Dominik Vogt wrote: > > [snip] > > 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.
The commands are not language constructs, but the return codes are. To be honest, I limited the return codes to conditionals because it will be a major effort to properly define the correct return codes of all existing commands in a consistent way. To give all commands a return code, each and every command has to be modified and the return codes defined carefully. > But we probably should first see some real > life usages to decide about this. Agreed. [snip] > > > 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. How about the names IfRc/SwitchRc or RcIf/RcSwitch instead? (And if we have a 'Preserve' prefix it should be 'PreserveRc'. > > > 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 Doh. Boolean values can't be 0 or one. Nothing of the above could have worked. You to use symbolic names like "True" and "False". Anyway, I've fixed it. The argument can now be either a number (0/1/-1) or a symbol (Match/NoMatch/Error). The example works now for me with both commands. 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]
