capital L

[Fairlight]

With neither thought nor caution, Kenneth Brody blurted:
> 
> So after >20 years of filePro compares being case-insensitive, you
> didn't know that the compare would be case-insensitive?  Why is this
> a surprise to _anyone_?

I don't mean to be derisive or offensive, but the short answer is, "I keep
expecting operands to do the sensible thing."  I'm not sure -why- I keep
making that mistake, but there it is.  :)  

It's like driving 10 different makes and models of car and knowing that
they all run fine when you put in petrol; you find it mind-boggling when
you buy one and that time-tested relationship doesn't actually stand up.

> And, given that filePro fields are not C strings, why would you assume
> that instr() is a wrapper for strstr()?  (Or any filePro field routine
> being a wrapper for any C string function?)

Short version?  

open() close() opendir() nextdir() closedir() write() read()
bind() socket() connect() accept() listen()  ...amongst possible others

[Yes, I have the belief that fP nextdir() is an extended wrapper around C
readdir().]

Since 4.8 when raw I/O was introduced, I -thought- things were getting a
bit more standardised on normalised C functions.  The networking only
underlined the belief.  That a practise in one area of newer code would
carry over into other areas was possibly wishful thinking, but also an
extrapolation to some extent.

Actually, I think I said it wrong the first time, btw.  I think I had
decided a while back that I thought substr() was a wrapper for strstr() and
instr() was a wrapper for strchr().  Apparently they're not. :)

mark->