Re: Quite old patch adding new Test condition

2005-08-12 Thread Mikhael Goikhman
On 12 Aug 2005 08:45:07 +, Mikhael Goikhman wrote:
 
  I need a tool to check if some settings was set before and act
  acordingly (eg. I need to check if a variable was set before, to not
  overwrite it, or check the value of a variable and load apropriate
  config file).
 
 I.e. you need something like these Test conditions:
 
   (IsEnvSet var_name)
 
 that is false if the value is unset or , or/and:
 
   (MatchEnv var_name pattern)

It was easy to implement, so I just added these Test conditions.

Any comments are welcome.

Regards,
Mikhael.



Re: Quite old patch adding new Test condition

2005-08-12 Thread Rafal Bisingier
On Fri, Aug 12, 2005 at 08:45:07AM +, Mikhael Goikhman wrote:
 On 11 Aug 2005 09:21:41 +0200, Rafal Bisingier wrote:
  
  On Thu, Aug 11, 2005 at 05:09:26PM +1000, Cameron Simpson wrote:
   On 09Aug2005 11:16, Mikhael Goikhman [EMAIL PROTECTED] wrote:
   | On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
   |  I personaly don't like perl's string operators (eq, ne, etc.)
   | 
   | Is it because of perl or because of eq, ne names? These names are
   | also tcl's expr operators, and you may find them in the test(1) man 
   page.
   
   Where they are conveniently swapped in application. The -lt etc are
   numeric operators in test(1), because = and != are already taken for
   lexical comparison.
  
  That's another reason to not use this silly notation... ;-)
 
 I am not sure whether this discussion is technical still. If you perform
 a Google search for 'programming language eq ne le lt ge gt' you will
 find a dozen or two of languages.

I know about it. I had to learn in the past about 10 different
programming languages, but I still think this kind of operators makes
only a mess. ;-)

 People use these names and know what they mean.

My point is not the problem with the meaning (at least not the biggest
one), but difficulty in telling apart operators from compared values
(eg. a comparision like this equal ne notequal instead of this
equal != notequal). This is only my point of view, but I will defend
it as long as I can... ;-)

 If we are to have two sets of comparison operators (that your
 patch seems to do), then using different names would be silly. :)

I don't need 2 sets of operators. I make it this way because it was
simple to do, nothing more. I needed only the integer part.
But I can disagree than with 2 sets of operators it'd be extremely silly
to use different names (inventing a wheel for the second time was not my
point). ;-)

 In any way, I am against to start to add the elements of a scripting
 language (inlcuding string and integer concepts) before 2.6 is out.
 There are already several ways to achieve what this Compare patch does.
 Additionally, I didn't hear users requesting this functionality. It seems
 you don't need it yourself, you wrote:
 
  I need a tool to check if some settings was set before and act
  acordingly (eg. I need to check if a variable was set before, to not
  overwrite it, or check the value of a variable and load apropriate
  config file).
 
 I.e. you need something like these Test conditions:
 
   (IsEnvSet var_name)
 
 that is false if the value is unset or , or/and (case insensitive):
 
   (MatchEnv var_name pattern)
 
 I am not against adding one or another such condition.

Well, I tried to make it as flexible as I can, but maybe that was not
the best idea ;-) Your solution is equaly good for me and if it makes
into fvwm, then it would be even better. ;-)

-- 
Rafal Bisingier


pgpHi2eSyKxR2.pgp
Description: PGP signature


Re: Quite old patch adding new Test condition

2005-08-12 Thread Rafal Bisingier
On Fri, Aug 12, 2005 at 11:36:51AM +, Mikhael Goikhman wrote:
 On 12 Aug 2005 08:45:07 +, Mikhael Goikhman wrote:
  
   I need a tool to check if some settings was set before and act
   acordingly (eg. I need to check if a variable was set before, to not
   overwrite it, or check the value of a variable and load apropriate
   config file).
  
  I.e. you need something like these Test conditions:
  
(IsEnvSet var_name)
  
  that is false if the value is unset or , or/and:
  
(MatchEnv var_name pattern)
 
 It was easy to implement, so I just added these Test conditions.
 
 Any comments are welcome.

I can say only one thing: THANK YOU. :-)

-- 
Rafal Bisingier


pgpVx869tP3qL.pgp
Description: PGP signature


Re: Quite old patch adding new Test condition

2005-08-11 Thread Cameron Simpson
On 09Aug2005 11:16, Mikhael Goikhman [EMAIL PROTECTED] wrote:
| On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
|  I personaly don't like perl's string operators (eq, ne, etc.)
| 
| Is it because of perl or because of eq, ne names? These names are
| also tcl's expr operators, and you may find them in the test(1) man page.

Where they are conveniently swapped in application. The -lt etc are
numeric operators in test(1), because = and != are already taken for
lexical comparison.
--
Cameron Simpson [EMAIL PROTECTED] DoD#743
http://www.cskk.ezoshosting.com/cs/

What I want is Facts. Teach these boys and girls nothing but Facts.  Facts
alone are wanted in life. Plant nothing else, and root out everything else.
- Charles DickensJohn Huffam   1812-1870  Hard Times [1854]



Re: Quite old patch adding new Test condition

2005-08-09 Thread Rafal Bisingier
I've thought Mikhael will comment on this and I didn't make a mistake...
;-)

On Mon, Aug 08, 2005 at 10:59:16AM +, Mikhael Goikhman wrote:
 On 08 Aug 2005 11:27:16 +0200, Rafal Bisingier wrote:
 
  This patch ads new test-condition to the Test function named
  Compare.
  With it one can do simple comparisions of numbers or strigs without
  using PipeRead and shell subprocesses. This could be very handy in
  conditional configuration (a simple if-else is possible with it).

 I don't really like this verbose syntax:

   Test (Compare string 1 strcmp string 2) DoSomething

 The following syntax is better:

   Compare (string 1 eq string 2) DoSomething

Well, this syntax is strightly derived from existing syntax and this is
the only reason of it's form.

 Perl's operators (eq, ne, lt, gt, le, ge and cmp) are string
 equivalents of numerical operators (==, !=, , , =, =, ).
 Not sure there is a need for 2 sets of operators rather than
 just string operations, but ok.

I need it only for integer comparision, so didn't take much care about
string operations. I've added strcmp only for completness and because it
was easy to do ;-)
I personaly don't like perl's string operators (eq, ne, etc.) and I
don't see any reason to have le, lt, ge and gt operators other than
completness. I think much more useful would be case insensitive
comparision, but that's only my point of view.

 Having separate command for this is not really a problem, just like we
 have separate command for TestRc.  And if already do this, then
 simply:

   If (string 1 eq string 2) DoSomething

When I made this patch I wanted it to make as little changes to fvwm
source as possible and make the patch as simple as I only can in the
hope
that this can help in merging it into fvwm...

 But then we had another similar If patch by Scott, IIRC.

Yes, there is a patch from Scott adding a complete if-elseif-else-endif
syntax, but it's far more bigger, much more complicated and adds
completely new syntax. From the other side Scott's patch is more
functional and probably simpler to use in complicated configuration.

I don't care which patch can be included into fvwm now (it could be even
both of them), I just wanted to have some kind of conditional syntax
aviable in fvwm config file without the need of external commands run by
PipeRead.

PS. Scott's patch was planed to be included after 2.6 release, but I
don't think 2.6 will came out in near future and I need this kind of
functionality right now (or more precisely I need it since october'04 ;-)

-- 
Greetings
Rafal Bisingier


pgp1cDPB3n3tw.pgp
Description: PGP signature