Julien wrote:

Hello Petr, I am on linux so I cannot test your problem. But maybe you can try to replace anti slash  \ by slash / in your example file path: C:/Petr/ChucK/examples/basic/whirl.ck

Thanks for the tip. I have two things to say here, one positive, the other not so positive. #1. It works, so that's the good news. I would never ever have the idea to try this thing on Windows where noone would normally do things like this. So if it turns out to be a usable workaround, I think it deserves being documented somewhere. An unaware user who's just learning to use Chuck and who runs Windows will never think of this idea by himself/herself and will be wondering why on earth it doesn't work the way it's supposed to. An unaware user should definitely be informed that this workaround exists, otherwise he/she'll think that there's just no way to get it working in Windows. #2. Windows uses backslashes essentially throughout its entire path mechanism, even internally. That means that if I tell Windows that the "ck" file extension should be associated to "chuck.exe" and then type "whirl.ck" alone on the command line, Windows translates it internally to something like "C:\Program Files\ChucK\bin\chuck.exe whirl.ck". That is, there are several backslashes in the submitted command line but they're not something that I've typed in, they're the result of Windows translating my shortened command line to its full version. If "chuck.exe" is unable to handle backslashes, the documentation would have to explain that Windows users should A) always run Chuck by specifying the entire pathname to the "ck" file on the command line, and B) never ever associate the "ck" extension with chuck.exe to run Chuck by means of that association. I should also add that the B) requirement would be highly inconvenient for most Windows users because then it would be impossible to just click on a "ck" file (in the file explorer) and expect Chuck to do what it's supposed to.

ChucK is coded in C++ and in this language \ is used for special characters in strings (\n means carriage return \t means tabulation ...).

Aha, I see. So the program wrongly interprets every backslash as a start of an escape sequence. But hang on, there must be something else at fault here. If the C++ escaping syntax were indeed such a conflicting thing, then there couldn't ever exist such applications as Microsoft Visual C++. That's a Windows application from the very start and there are tons of code being compiled using Microsoft Visual C++. A proof that it can work is the fact that there are applications that are coded in C++ as well and never had any trouble with backslashes on Windows. Even many proprietary Windows applications are compiled using MSVC. And if MSVC is a Windows application from the very start and it's being used for compiling C++ code, this necessarily is an important message. Also, there are cross-platform applications written in C++ and even these seem to work fine in Windows -- i.e. Audacity or MuseScore quickly comes to mind. I think we should hear an opinion of someone who does have some experience with Windows in this regard. Petr -- Tento e-mail byl zkontrolován na viry programem AVG. http://www.avg.cz