Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Unexpected result from @index

Apr
393
13
TCC (x64) Version 28.02 Build 18 [28.02.18]
Microsoft Windows 11 Home (21H2) [10.0.22000.1098]

If I use @index to find the offset of "bar" within the string "foobar":
Code:
c:\>echo %@index[foobar,bar]
3

then it returns a zero-based count.

If, however, the string is quoted:
Code:
c:\>echo %@index["foobar",bar]
4

the answer is different; it appears to be a 1-based count.

I wasn't expecting a different result. Is this a bug or is there a reason for the different answer?
 
It doesn't skip the quotes.
Do you think it’s designed that way? It seems odd, since the help points out that if a string contains a comma it has to be quoted, which makes sense, but it doesn't then make sense to me that it counts the quotes as part of the string.

I’ve worked around it by removing any commas before using @index, so it’s not a showstopper for me, but if it’s WAD I’d like to understand the rationale for it.
 
Do you think it’s designed that way?
I don't know. Maybe Rex will chime in. I think it has always been that way. In general, quotes are left in parameters. And, who's to say whether the user wants them removed or not?
 
I just tested it on 4DOS Version 8.00;
Code:
C>echo %_4ver
8.00

C>echo %@index["foobar",bar]
4
...so it's been this way for a long time.

Joe
 
I just tested it on 4DOS Version 8.00;
Code:
C>echo %_4ver
8.00

C>echo %@index["foobar",bar]
4
...so it's been this way for a long time.

Joe
Thanks Joe, it must be intentional then. I've been a user since the days of 4DOS and have never encountered it before - I've obviously never previously had cause to use @index with a string that contains commas.

I've worked around it, so no worries.
 

Similar threads

Back
Top