fredebec
France
Asked
— Edited
Resolved by ptp!
Hi,
I have a very strange issue with File.AppendString.
I have a very simple python script to write a text in a file:
file = "C:\Users\FredWin\Documents\ARC\Scripts\ten.txt"
File.Delete(file)
File.AppendString(file, "text")
but it returns me
Start
Caractères non conformes dans le chemin d'accès.
Done (00:00:00.0224805)
(trad:"Illegal characters in the path").
What is very strange is that some really simple file names are problematic and others are not.
For example "nine.txt" or "ten.txt" return the error, but not "eight.txt" or "eleven.txt". Another example: if I use files such as "10.txt", "20.txt" or "30.txt", I have the error, but if I use "40.txt", "50.txt" and above, I have not.
I am really puzzled and I fail to see any logic in it.
Any idea what happens?
Edit: it seems to be specific to Python, I have not the same issue with EZ-scripts...
Related Hardware EZ-B v4
Related Control
Script
The problem you are experiencing is related to the escaping character "" and is common to Javascript, Python, Java, C#, C++, C, Objective-C, Swift, and probably many other languages the exception so far is VBScript and EZ-Script.
So when you want to use a specific character in a string you use the escape char [b][/b] some examples:
Python handles the escaped strings, doing the transformation, string is sent to ARC File class, then to windows file systems APIS, generating the error you are observing.Solution: escape the slash e.g. "C:\Users\FredWin\Documents\ARC\Scripts\ten.txt"
Python has a few solutions to solve and simplify some problems, but, you are mixing implementations e.g. Python with Arc's File object and simple things like using the universal path concept e.g. "c:/Users/FredWin/Documents/Arc/Scripts/ten.txt" may not work outside of the Python standard library.
Thanks @ptp. It works!
It is really strange, though, that it works systematically for some files (ex: "eight.txt") and for other it systematically doesn't (ex: "ten.txt"), with the exact same syntax... The magic of informatics, I guess
There is no magic
"c:\SomeFolder\eight.txt" => \e is not a valid escaped character is ignored and the final strings is: "c:\SomeFolder\eight.txt" "c:\SomeFolder\ten.txt" => \t is a TAB (value 9 in ASCII table) is translated and the final string is "c:\SomeFolderb[/b]ten.txt"
OK, I see the logic with the escaped characters. But just out of curiosity, why is it not working for "3.txt", "30.txt", "4.txt" and "5.txt", but it works for "40.txt" and "50.txt" ?
Short answer: \3 = ASCII char 3 \30 = ASCII char 24 \40 = ASCII char 32 = Space \50 = ASCII char 40 = ( The first printable char in ASCII is the space, decimal value 32 or octal value 040 so: \0 to \39 will be translated to a non printable character and will be invalidated by the filesystem API calls.
Food for the brain:
String literals e.g. \000 and \0x \t etc: https://docs.python.org/2.0/ref/strings.html
ASCII table in decimal, octal and hex: http://www.asciitable.com/
Octal numeral system: https://en.wikipedia.org/wiki/Octal
Decimal (10) base to Octal (8) base: https://www.youtube.com/watch?v=ayul1fmZd0Y
Octal base (2 ^3) to Decimal (10 ^ 1) base: https://www.youtube.com/watch?v=YCM2JReWS10
OK, I get it! Thanks again for your help. I learned a lot, as usual