find/last/part behaviour
[1/4] from: andreas::bolka::gmx::net at: 22-Dec-2002 1:53
I noted a quite odd behaviour of 'find when combining /last and /part
refinements - at least it is not what I expected.
Basically I wanted to achieve "ends with" functionality - some
examples to illustrate the desired behaviour:
ends-with? "1234567890" "890"
; == true
ends-with? "1234567890" "0"
; == true
ends-with? "1234567890" "9"
; == false
Now I thought that combining the /tail and /part refinements of 'find
would naturally map to this:
/part -- Limits the search to a given length or position.
range -- (Type: number series port)
/last -- Backwards from end of string.
/reverse -- Backwards from the current position
Silly me, it seems, as internal 'find priorities make /part limit the
string to be searched _first_ and then search backwards within that
string. Which leads to the following:
found? find/last/part "1234567890" "890" 3
; == false
If you agree that /part should have a "higher priority" than /last,
this behaviour is what would be desired.
However, there is a solution to achieve what was desired. Combine
/reverse and /part and use 'tail up-front:
found? find/reverse/part tail "1234567890" "890" 3
; == true
And it is this notion, that /reverse has a "higher priority" than
/part while /last has not, that I don't think is consistent. Any ideas
how this consistency problem could be resolved? Is it a problem at
all?
--
Best regards,
Andreas mailto:[andreas--bolka--gmx--net]
[2/4] from: anton:lexicon at: 22-Dec-2002 14:11
I usually use this to check the extension of a filename
etc.:
"" = find/last/tail "01234" "234"
;== true
You might propose to change the find/reverse inline help from:
/reverse -- Backwards from the current position.
to:
/reverse -- Backwards from the current position (or end of
range if /part specified).
I can't make up my mind which is better.
I think the first way is simpler to implement and doc,
but the second way is possibly more consistent, as you say.
Anton.
[3/4] from: hallvard:ystad:helpinhand at: 23-Dec-2002 10:26
I've been checking file extensions like this:
found? find skip tail filename -4 ".ext"
found? find skip tail filename -3 ".gz"
found? find skip tail filename -7 ".tar.gz"
.. so as usual, there is a multitude of ways to do things. I like your way better, Anton,
because it doesn't require a specification of how many characters to check (whereas I
have to change the number of 'skip each time).
Merry X-mas, everyone.
~H
Dixit Anton (04.11 22.12.2002):
[4/4] from: nitsch-lists:netcologne at: 23-Dec-2002 20:42
Hi Anton, Hallvard,
Hallvard Ystad wrote:
>I've been checking file extensions like this:
>
>found? find skip tail filename -4 ".ext"
>found? find skip tail filename -3 ".gz"
>found? find skip tail filename -7 ".tar.gz"
>
>.. so as usual, there is a multitude of ways to do things. I like your way better, Anton,
because it doesn't require a specification of how many characters to check (whereas I
have to change the number of 'skip each time).
>
And yet another way
parse filename[thru ".ext"] ;)
>Merry X-mas, everyone.
>~H
<<quoted lines omitted: 5>>
>> ;== true
>>
Anton, eventually
>> find/last/tail "0123456" "234"
== "56"
>>
[snip]
-volker
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted