On 27 Feb 2002 12:53:05 +0100, Dominik Vogt wrote: > > 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.
It is easy to do that all commands return Success without changing any. > > > > 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. > > How about the names > > IfRc/SwitchRc or RcIf/RcSwitch > > instead? (And if we have a 'Preserve' prefix it should be > 'PreserveRc'. I still prefer the name "Status" (or if you like "OnStatus"). But if we want some mnemonics, how about "On" and "PreserveStatus" (I am speaking about general status codes, not only conditionals): Current (Raised) Lower On (NoMatch) Current Raise and: Read file1 PreserveStatus On (Success) Read file2 On (NoFile) Read file3 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]
