Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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