| Author |
lsearch -regexp difficulty, why won't it work?
|
|
| Andrew Falanga 2005-04-21, 4:00 pm |
| 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.
| |
| Don Porter 2005-04-21, 4:00 pm |
| 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 |
|_______________________________________
_______________________________|
| |
| Donald Arseneau 2005-04-21, 8:58 pm |
| Andrew Falanga <not_real@hp.com> writes:
> other code writing practices, I must implement this functionality using the
> "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
| |
| Arjen Markus 2005-04-22, 8:58 am |
| 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
| |
| Kaitzschu 2005-04-22, 8:58 am |
| 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
| |
| lvirden@gmail.com 2005-04-22, 4:01 pm |
|
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 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
| |
| Andrew Falanga 2005-04-22, 4:01 pm |
| 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.
| |
| Donald Arseneau 2005-04-23, 8:57 am |
| Andrew Falanga <not_real@hp.com> writes:
> The coding practices to which I refer require that all procs written use only
> 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
|
|
|
|