StrCmp fails on string from web server

Hi guys 🙂

anyone can help figuring out why is this failing? 🤪
im drawing blank now for days; im baffled by this odd behavior when it shoudl be straight forward 😱

    FileOpen $0 "$TEMP\tmp.txt" "r"
        FileRead $0 $1
        FileClose $0
        Delete $TEMP\tmp.txt
// everything is working OK to this point 
// $1 contains the text from tmp.txt (single word VALID or INVALID)
// then it all goes south from here; doesn't matter what i do i end up on VALID
// LogicLib is in place and functioning for other element just fine in other sections of the script
// i tried StrCmp instead on ly to get the same exact behavior; always INVALID,
        ${If} $1 == "INVALID"
          MessageBox MB_OK "INVALID"
          Abort
        ${Else}
          MessageBox MB_OK "VALID"
        ${EndIf} 

TIA

Chris

LogicLibs == is just syntax sugar and calls StrCmp under the hood.

My guess is that $1 contains something unexpected, invisible characters perhaps. Unless it is at the end of the file there might be a newline pair at the end of the string...

Thank you very much Andres,
i have called $1 few time inside an error message; just to see what it holds,
it seems to be holding the right value,

this command is the first set of instructions i am running in On.init
there are no instruction before that,

part of the command i run inetc::POST to my server;
which answers back with VALID or INVALID; stored in $TEMP\tmp.txt

i can grab the text off tmp.txt no issue, i assign it to $1,
i can call it to verify the right data is present (which it is),

but than when i compare it always fail,
at this point im pretty sure im doing something wrong; i just cant put my finger on it,

since yo mention character sets...
the only thing remotely possible i can think of is the use of

header('Content-Type: text/plain'); 

on my server side php script that answers;
in my mind this should make things less complicated!?

the strange part is...
i have a similar instruction down the script; it does very similar verification (user name and email) that is working just fine,

for some odd reason this new piece of snippet i copied off an existing part of the same script and modified; refuses to play ball when used earlier in the script,

TIA

Chris

i think i got it working 🙂
following your hints i decided to try and trim before compare,

    FileOpen $0 "$TEMP\tmp.txt" "r"
        FileRead $0 $2
        FileClose $0
        Delete $TEMP\tmp.txt
        Push $2
        Call Trim
        Pop $R5
        ${If} $R5 == "INVALID"
          MessageBox MB_OK "INVALID"
          Abort
        ${Else}
          MessageBox MB_OK "VALID"
        ${EndIf} 

it seems to be working now (i just hope i didn't break something else 🙂 )

Thank you Andres W00T

TIA
Chris

If you want to get to the bottom of this issue you could just look at the file in a hex-editor...

Thank you Anders,
im not sure inspecting temp.txt in hex editor will yield a lead to the cause,
its the outcome we will be testing there,

i am using Unicode with a 64bit forked build, possibly the source of this issue,
im glad your suggestion and lead worked out the first try, i was chasing my tail for days not sure why its faulting when it shouldn't,


TIA
Chris

The problem character has to come from somewhere. It is either in the file on disk or comes from a bug in FileRead, it would be interesting to know which...

Not telling us that you are not using an official build in your first post is also really stupid!

my bad Anders 😱
Ive used this build for a long time now,
it is authored by a respectable member who prefers to remain anon,

i am using similar function in another section of the script that was not effected,
thats why i neglected to mention the unofficial build; wasn't worried it is a build issue,
it has been very reliable to me so thus far,

temp.zip attached contains regenerated faulting temp.txt,
personally i wouldn't know what to look for,


TIA
Chris

Just as I expected, it contains a linefeed+newline pair after the other characters:



You would have seen it if you had done a bit of "debugging":

MessageBox mb_ok "|$2|"

would display as

|VALID
|

and not

|VALID|

If you had looked at the file properties you would also have seen that it is 7 bytes and that does not make sense for 5 ASCII characters...

---

If you have been using a build for a long time you might want to upgrade because there have been some 64-bit changes during the beta/rc phase. If that build is using the default build configuration you can even use the official makensis from NSIS 3, all you need is the 64-bit stubs and plugins 🙂

Thank you Anders 👍
now the question is... whats causing this?
is there anything i should do to investigate this further?

im fairly new to NSIS and still learning the ropes,
debugging is not my strong suite 🙁
i run my simple debug this way

MessageBox mb_ok "$2"

learning every day 😉

also i had no idea there is an official public 64bit build,
(the build I'm using is based on NSIS 3.02)
where should i start catching up on this?

TIA
Chris

It probably comes from the webserver. Look at your script that runs on your server (write vs writeline?) and maybe watch the HTTP traffic with Fiddler or Wireshark.

There is no official 64-bit build yet but the 32-bit compiler can output 64-bit installers if you get the 64-bit stubs and plugins for 3.0 final from your source. And there is no such thing as NSIS 3.02 and people that call it that are 1) wrong, and 2) in trouble when we release 3.02...

you are right!
I meant to say... 3.0b2 😉