Jump to content
Sign in to follow this  
readmedottxt

[Solved] Problem with FileReadLine

Recommended Posts

readmedottxt

Hello,

Trying to monitor (and provide feedback) for an unattended installation of SP2 for SQL 2005 by watching

C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt

I'm reading lines and reporting to a master DB various things like time began, progress, errors and completion from reading the log file.

Here's some code:

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 0)
        if $f = -1 then msgbox(0, "", "Could not open logfile")
        $line = ""
        While 1
            $l = FileReadLine($f)
            if @error then ExitLoop
            if StringLeft($l, 27) = "Product  " Then; had to use 'product  ' with 2 spaces so 'product version' is ignored
                $l2 = StringSplit($l, ":", 1)
                $l3 = StringStripWS($l2[2], 1)
            EndIf
            
            if StringLeft($l, 7) = "Status " Then
                $l4 = StringSplit($l, ":", 1)
                $l5 = StringStripWS($l4[2], 1)
                
                $line = $line & $l5 & ": " & $l3 & @CRLF
            EndIf
        WEnd
        if $line <> $line2 Then
            GUICtrlSetData($Report, $line)
            $line2 = $line
        EndIf

        FileClose($f)

I've had no luck here. If I open the text file in notepad and save it without changing anything, the code will correctly process and parse Summary.txt

So I opened the before and after Summary.txt files in xvi32 (win32 hex editor) and found two discrepancies:

Before saving with Notepad (as output by SP2) the text starts immediately, with the first word (represented in hex) being "Time"

54 00 69 00 6D 00 65 00

This cannot be read by the code. FileReadLine only returns one character "T" then every subsequent line read is blank.

After saving with Notepad, we get a leading FF FE before "Time"

FF FE 54 00 69 00 6D 00 65 00

Now it works correctly - the code can read and parse the code, I get the results I need.

Is this a bug in AutoIt or the way SP2 for SQL 2005 writes its text files?

How could I work around this?

Edited by readmedottxt

Share this post


Link to post
Share on other sites
enaiman

Wow - took me a while to find a way.

I didn't believe what you were saying at the begining but I've seen that it was true.

I tried to get the text from DOS, using StdOUT, reading the file, reading lines ... nothing worked.

Finally I've found a "messy way" to do it: to open it in a hidden notepad window and get the text and closing it after that.

It is messy because I use another app to get the text content and I'm using "Control" commands (which depend on using app's title ...)

You will have to change my script to reflect your file's location (pay attention to Run command when file path contain white spaces) and the notepad window's title. If you do this, you will be fine.

Run("notepad C:\temp\original.txt", "",  @SW_HIDE)              ;open the file (hidden)
Sleep(200)                                                      ;give time to open
$content = ControlGetText("Original.txt - Notepad", "", "Edit1");get text
MsgBox(0, "Content", $content)
WinKill("Original.txt - Notepad")                               ;kill hidden notepad

SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites
Skruge

It helps to understand why it isn't working, and what the notepad workaround is actually doing.

Seeing every other byte value as zero is a dead giveaway that you're dealing with Unicode data.

The problem is that there are several Unicode formats, and in order to determine which is in use, there's usually a Byte Order Mark (BOM) added to the beginning of the file. (That's what notepad did for you).

See this page for more information: http://unicode.org/faq/utf_bom.html

Now, it could be that SQL forgot to add the BOM, or maybe it tried to do it when it was finished writing but your script or some other process held the file open.

Without this data, AutoIt coudn't tell what format it was and defaulted to ANSI.

Either way, you can force AutoIt to open the file in UTF-16 mode by using FileOpen's mode 32.

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 32)

The moral of the story?

The wonderful thing about standards is that there are so many of them to choose from.


[font="Tahoma"]"Tougher than the toughies and smarter than the smarties"[/font]

Share this post


Link to post
Share on other sites
enaiman

:P

Thanks Skruge - that solved everything. Too bad I had no idea about that (It would have saved me some time) and I didn't think to play with different modes for opening a file.

Anyway - today I have learned something new :unsure: Isn't that wonderful? :D


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites
readmedottxt

Wow - took me a while to find a way.

I didn't believe what you were saying at the begining but I've seen that it was true.

I tried to get the text from DOS, using StdOUT, reading the file, reading lines ... nothing worked.

I tried all that too, I couldn't believe such a simple piece of code wasn't working as it should.

It helps to understand why it isn't working, and what the notepad workaround is actually doing.

Seeing every other byte value as zero is a dead giveaway that you're dealing with Unicode data.

The problem is that there are several Unicode formats, and in order to determine which is in use, there's usually a Byte Order Mark (BOM) added to the beginning of the file. (That's what notepad did for you).

See this page for more information: http://unicode.org/faq/utf_bom.html

Now, it could be that SQL forgot to add the BOM, or maybe it tried to do it when it was finished writing but your script or some other process held the file open.

Without this data, AutoIt coudn't tell what format it was and defaulted to ANSI.

Either way, you can force AutoIt to open the file in UTF-16 mode by using FileOpen's mode 32.

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 32)

The moral of the story?

Prior to reading the link, I had some knowledge on LE & BE encoding (x86 vs 68xxx days) but since it hasn't intefered with my work for a decade, I didn't think it could be affecting "plain" text files from the same platform....

Something so simple and straightforward, yet so frustrating when you dont understand and apply the technology.

Thank you for the explanation! Like eniaman said, you learn something new every day.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.