[Beta bug?] _FileWriteToLine damages the file (3.3.9.20+)

[monter]

Hello, I just discovered bad thing. If I used _FileWriteToLine function in AutoIt3 beta since 3.3.9.20 and newer, after launching the file it's partially damaged itself. Older versions work correctly and there is no file damaging.
Look at the example and test on different versions - older and newer.
 
(Added): I think the problem is in IncludeFile.au3
v.3.3.9.20, line 677:

Local $aArray = StringRegExp(@CRLF & $sFileRead & @CRLF, "(*BSR_ANYCRLF)([^\R]*)(?:\R)(?:\R$)?", 3)

v.3.3.9.19, line 683:

Local $aArray = StringRegExp(@CRLF & $sFileRead & @CRLF, "([^\r\n]*)(?:\r\n|\n|\r)(?:[\r\n]$)?", 3)

Maybe the pipe "|" I used is the reason?

#AutoIt3Wrapper_Res_Field=Release date|18.10.2013

partypooper, MrCreatoR?
 
P.S. Excuse me for strange characters in line number 5.
It's an online artifact, there is no such characters in my code.
 

expandcollapse popup

#region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_Res_Comment=http://monter.FM
#AutoIt3Wrapper_Res_Description=Example file showing beta bug since AutoIt3.3.9.20.
://////=__=..
#AutoIt3Wrapper_Res_LegalCopyright=monter.FM
#endregion ;**** Directives created by AutoIt3Wrapper_GUI ****
#include <Date.au3>
#include <File.au3>
Global $msg, $flg, $sec
$title = 'AutoIt3 - version ' & @AutoItVersion
FileChangeDir(@ScriptDir)
If StringReplace(@AutoItVersion, '.', '') > 33919 Then
    VerBug()
Else
    VerOK()
EndIf

FileInfo()

MsgBox($flg, $title, $msg, $sec)
If $flg = 48 Then Run('notepad.exe ' & @ScriptName)

Func VerBug()
    $msg = 'This version has just damaged this file.' & @CRLF & 'Fortunately I made the *.bak copy :)' & @CRLF & 'Look at this damaged script now.'
    $flg = 48
    $sec = 6
    FileCopy(@ScriptName, @ScriptName & '.bak')
EndFunc   ;==>VerBug

Func VerOK()
    $msg = "This version works fine and shouldn't damage this file."
    $flg = 64
    $sec = 3
EndFunc   ;==>VerOK

Func FileInfo()
    Opt('TrayIconDebug', 1)
    $strRes = '#AutoIt3Wrapper_'
    For $ln = 1 To 10
        $srchRes = StringInStr(FileReadLine(@ScriptFullPath, $ln), $strRes)
        If $srchRes > 0 Then
            $lr = $ln
            ExitLoop
        EndIf
    Next
    $strRes = '#AutoIt3Wrapper_Res_Field=Release date|'
    For $ln = $lr To $lr + 16
        $srchRes = StringInStr(FileReadLine(@ScriptFullPath, $ln), $strRes)
        If $srchRes > 0 Then
            $lnRes = $ln
            ExitLoop
        EndIf
    Next
    $rd = FileGetTime(@ScriptFullPath, 0, 0)
    _FileWriteToLine(@ScriptFullPath, $lnRes, '#AutoIt3Wrapper_Res_Field=Release date|' & $rd[2] & '.' & $rd[1] & '.' & $rd[0], 1)
    Global $dateRlse = $rd[2] & '.' & $rd[1] & '.' & $rd[0]
    FileSetTime(@ScriptFullPath, $rd[0] & $rd[1] & $rd[2] & $rd[3] & $rd[4] & $rd[5], 0)
EndFunc   ;==>FileInfo

FileWriteToLine_bug_Au3.3.9.20+.au3

Edited October 18, 2013 by monter

[Melba23]

monter,

I can confirm the problem - and add the fact that it appears to be assiociated with the function not picking up line endings correctly. This simple script shows the problem - under 3.3.8.1 it runs, under 3.3.9.21 it fails claimimg that there are not enough lines in the file:

#include <File.au3>
#include <Constants.au3>

$sText = "Line 1" & @CRLF & "Line 2" & @CRLF & "Line 3" & @CRLF & "Line 4" & @CRLF & "Line 5"

; Recreate file each time
$hFile = FileOpen("Test.txt", 2)
FileWrite($hFile, $sText)
FileClose($hFile)

; Display original file
$sText = FileRead("Test.txt")
MsgBox($MB_SYSTEMMODAL, "Org File", $sText)

; Change line
$iRet = _FileWriteToLine("Test.txt", 3, "Testing", 1)
If @error = 1 Then
    ; Announce error
    MsgBox($MB_SYSTEMMODAL, "Error", "File has less lines than $iLine parameter")
Else
    ; Display new file
    $sText = FileRead("Test.txt")
    MsgBox($MB_SYSTEMMODAL, "New File", $sText)
EndIf

I will move the thread to "Developer Chat" as it will get the attention it needs there.

M23

[Melba23]

Hi,

<snip>

M23

Second edit: Ignore all previous - the pattern was also failing in my SRE tester. The return display made it look as if the lines were being split where in fact it was just honouring the internal @CRLFs. I have now amended my tester code to make this more obvious. Sorry for any confusion.

Edited October 19, 2013 by Melba23

[jchd]

I was testing it and indeed it looks strange. I'll have a close look as soon as possible. I need to do concrete work all day, and I mean cinderblocks, cement, gravel, sand...

There are numerous regexp connoisseurs here.

[guinness]

I created that SRE by changing it from...

([^\r\n]*)(?:\r\n|\n|\r)(?:[\r\n]$)?

to...

(*BSR_ANYCRLF)([^\R]*)(?:\R)(?:\R$)?

For now I have reverted back to the old (working!) regular expression, though I am pretty sure it was working at some point. Sorry about that.

#include <Array.au3>

Local $sText = 'Line 1' & @CRLF & 'Line 2' & @CRLF & 'Line 3' & @CRLF & 'Line 4' & @CRLF & 'Line 5'

; Is \R working? Yes it is!
ConsoleWrite(StringRegExpReplace($sText, '(*BSR_ANYCRLF)\R', '__XXX__') & @CRLF)

; v3.3.9.21 - I would expect this is be simlar to the RE below.
Local $aSRE = StringRegExp($sText, '(*BSR_ANYCRLF)([^\R]*)(?:\R)(?:\R$)?', 3)
_ArrayDisplay($aSRE)

; v3.3.9.20
$aSRE = StringRegExp($sText, '([^\r\n]*)(?:\r\n|\n|\r)(?:[\r\n]$)?', 3)
; _ArrayDisplay($aSRE)

[Melba23]

guinness,

It is the first group ([^R]*) that is making it fail - but I do not see why.

M23

Edit: I think I have it:

 

"Note that in a character class, only d, D, h, H, p{}, P{}, s, Q...E, S, v, V, w, W, and x sequences retain their special meaning; b means the backspace character (Chr(8))"

So "R" is treated as a literal "R":

#include <Array.au3>

Local $sText = @CRLF & 'Row 1' & @LF & 'Row 2' & @CR & 'Row 3' & @CRLF & 'Row 4' & @CRLF & 'Row 5' & @CRLF ; Now Row not Line

; Is \R working? Yes it is!
ConsoleWrite(StringRegExpReplace($sText, '(*BSR_ANYCRLF)\R', '__XXX__') & @CRLF)

; v3.3.9.21 - I would expect this is be simlar to the RE below.
Local $aSRE = StringRegExp($sText, '(*BSR_ANYCRLF)([^\R]*)(?:\R)(?:\R$)?', 3)
_ArrayDisplay($aSRE)

; v3.3.9.20

$aSRE = StringRegExp($sText, '(*BSR_ANYCRLF)([^\n\r]*)(?:\R)(?:\R$)?', 3)
_ArrayDisplay($aSRE)

Edited October 19, 2013 by Melba23

[guinness]

OK, that now makes a ton of sense. Well I learnt something today. Would've thought R would have retained its special meaning in a class as well, cheers for debugging.

Edited October 19, 2013 by guinness

[Melba23]

guinness,

I will send you the doctor's bill for the treatment to stop my brain beeding!

And this very simple version seems to work fine in my tests:

#include <Array.au3>

Local $sText = @CRLF & 'Row 1' & @LF & 'Row 2' & @CR & 'Row 3' & @CRLF & 'Row 4' & @CRLF & 'Row 5' & @CRLF

; Is \R working? Yes it is!
ConsoleWrite(StringRegExpReplace($sText, '(*BSR_ANYCRLF)\R', '__XXX__') & @CRLF)

; v3.3.9.21
Local $aSRE = StringRegExp($sText, '(*BSR_ANYCRLF)([^\R]*)(?:\R)(?:\R$)?', 3)
_ArrayDisplay($aSRE)

; This works
Local $aSRE = StringRegExp($sText, '(*BSR_ANYCRLF)(.*)(?:\R)(?:\R$)?', 3)
_ArrayDisplay($aSRE)

M23

[jchd]

Would've thought R would have retained its special meaning in a class as well

That's not possible: a character class always stands for a single character but R can be set to match two (just like in our use case).

[guinness]

That's not possible: a character class always stands for a single character but R can be set to match two (just like in our use case).

But then why are r & n treated as their special meanings?

[jchd]

Because both r and n code for just one character. The mere possibility that users employ (*BSR_ANYCRLF) for instance, opens the possibility that R matches the two-character newline sequence rn atomically. This would contradict the fact that a character class matches a single character.

[Melba23]

jchd,

So what do we go with now as both these patterns seem to work?

(*BSR_ANYCRLF)([^nr]*)(?:R)(?:R$)? or (*BSR_ANYCRLF)(.*)(?:R)(?:R$)?

M23

[guinness]

I have have reverted back to the previous working version. Unless you feel it should be changed?

[Melba23]

guinness,

As long as it works I am happy any RegEx.

M23

[guinness]

I like the first one of your suggestions. Should have stated that before.

[guinness]

Did anyone from here create this ticket? >> #2509

Edit: Set the resolution to fixed, unless there is a new bug I was unaware of.

Edited October 20, 2013 by guinness

[ldub]

I dit wrote the ticket #2509
It's ok now,

Thank's

[guinness]

I dit wrote the ticket #2509

It's ok now,

Thank's

OK. Thanks for coming forward.