lsearch -regexp difficulty, why won't it work?

Ok,

I'm writing a proc that may or may not get passed a timeout value.  Due
to other code writing practices, I must implement this functionality
using the "args" argument rather than simply saying

proc procName { yadda { timeout val } } { }

construct.

So, in parsing my args list I'm trying to use lsearch to accomplish this
as in the following example:

lsearch -regexp {^[0-9]+$} $lArgs
# lArgs contains args after string tolower

This doesn't work.  In trying to figure out why I've tried the following
loop which also doesn't work:

set lst "arg1 450"
foreach x $lst {
regexp -inline {^[0-9]+$} $x
}

However, when not working with lists but rather doing:

regexp -inline {^[0-9]+$} 4432100933

Works as expected.  So, what gives?  What little TCL idiocyncrosy am I
missing?  Does this have something to do with how the variable is
actually being stored in memory?  Is lsearch presenting the data in a
way that *something* is preventing this regular expression from
matching?  I do have a restriction on me in that I should use the ^ and
$ in the regexp because the possibility of other numbers being passed to
function does exist.



---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled.  I do not wish my account at HP to
become a spam haven.

Andrew Falanga wrote:
> This doesn't work.  In trying to figure out why I've tried the following
> loop which also doesn't work:
>
> set lst "arg1 450"
> foreach x $lst {
>    regexp -inline {^[0-9]+$} $x
> }

Why do you believe this doesn't work?  It works for me:

% set lst "arg1 450"
arg1 450
% foreach x $lst {
puts [regexp -inline {^[0-9]+$} $x]
}

450
%

--
| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
 |_______________________________________
_______________________________|

Andrew Falanga <not_real@hp.com> writes:

> other code writing practices, I must implement this functionality using th
e
> "args" argument rather than simply saying
>
> proc procName { yadda { timeout val } } { }

Based on this statement I wonder why you are trying to use regexp.
You can get the same effect using:

if {[llength $args]>1} {
set timeout [lindex $args 1]
} else {
set timeout 60
}

but shorter is

set timeout 60
foreach {yadda timeout} $args break

Then you can test $timeout for validity.

Disclaimer: I cannot imagine what "other code writing practices"
apply the constraints.


--
Donald Arseneau                          asnd@triumf.ca

Andrew Falanga wrote:
>
> Ok,
>
> I'm writing a proc that may or may not get passed a timeout value.  Due
> to other code writing practices, I must implement this functionality
> using the "args" argument rather than simply saying
>
> proc procName { yadda { timeout val } } { }
>
> construct.
>
> So, in parsing my args list I'm trying to use lsearch to accomplish this
> as in the following example:
>
> lsearch -regexp {^[0-9]+$} $lArgs
> # lArgs contains args after string tolower
>
> This doesn't work.  In trying to figure out why I've tried the following
> loop which also doesn't work:
>
> set lst "arg1 450"
> foreach x $lst {
>    regexp -inline {^[0-9]+$} $x
> }
>
> However, when not working with lists but rather doing:
>
> regexp -inline {^[0-9]+$} 4432100933
>
> Works as expected.  So, what gives?  What little TCL idiocyncrosy am I
> missing?  Does this have something to do with how the variable is
> actually being stored in memory?  Is lsearch presenting the data in a
> way that *something* is preventing this regular expression from
> matching?  I do have a restriction on me in that I should use the ^ and
> $ in the regexp because the possibility of other numbers being passed to
> function does exist.
>
>

One problem that I can see: foreach does not return a value. You would
have to use:

set success 0
foreach x $lst {
if { [regexp -inline (^[0-9]+$} $x] } {
set success 1
break
}
}

or something similar.

But there are plenty of other solutions as Donald Arseneau indicates.
Let me add: [string is integer -strict $x] - easier than the regexp.


Regards,

Arjen

On Fri, 22 Apr 2005, Arjen Markus wrote:

> But there are plenty of other solutions as Donald Arseneau indicates.
> Let me add: [string is integer -strict $x] - easier than the regexp.

foreach z {123 -123 0x123 09121233 82956256298562} {
puts "$z is[expr {[string is integer -strict $z] ? {} : { not}}]\
plain numbers."
}

--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done

According to Andrew Falanga  <not_real@hp.com>:
:lsearch -regexp {^[0-9]+$} $lArgs
:# lArgs contains args after string tolower
:
:This doesn't work.  In trying to figure out why I've tried the following
:loop which also doesn't work:
:
:set lst "arg1 450"
:foreach x $lst {
:   regexp -inline {^[0-9]+$} $x
:}

Try this and see:
# set lst "arg1 450"
arg1 450
% foreach x $lst {
set a [regexp -inline {^[0-9]+$} $x]
puts "a = $a"
}
a =
a = 450
%

--
<URL: http://wiki.tcl.tk/ > MP3 ID tag repair < http://www.fixtunes.com/?C=17038[/<...rg/NET/lvirden/ >

Donald Arseneau wrote:
> Andrew Falanga <not_real@hp.com> writes:
>
> 
>
>
> Based on this statement I wonder why you are trying to use regexp.
> You can get the same effect using:
>
> if {[llength $args]>1} {
>     set timeout [lindex $args 1]
> } else {
>     set timeout 60
> }
>
> but shorter is
>
> set timeout 60
> foreach {yadda timeout} $args break
>
> Then you can test $timeout for validity.
>
> Disclaimer: I cannot imagine what "other code writing practices"
> apply the constraints.
>
>

The coding practices to which I refer require that all procs written use
only the args argument versus spelling out expected arguments.  Further,
the proc I'm modifying already "accepts" one option argument and I'm
adding another.  Thus, I can never guarantee in what order they will
appear.  Thus rendering any use of lindex with hard coded index values
useless.

Thanks to all for the suggestions.

---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled.  I do not wish my account at HP to
become a spam haven.

Andrew Falanga <not_real@hp.com> writes:

> The coding practices to which I refer require that all procs written use o
nly
> the args argument versus spelling out expected arguments.

... which sounded entirely contrived ...

> Thus, I can never guarantee in what order they will appear.

Ah!  Having no *positional* arguments is a good reason to use
$args.  And what I suggested with foreach *is* for positional
arguments, just like the argument-list with defaults you said
you would have used.

Most of the existing code for random $args handling is directed
towards switches/options. The core uses a proc tclParseConfigSpec.


--
Donald Arseneau                          asnd@triumf.ca