ChucK mistaking directory delimiters for escape characters on Windows.

[ericheep]

On Windows using CMD or PowerShell, ChucK seems to mistake directory delimiters for escape characters. This is especially tricky when autocomplete in these environments always prefixes the current directory .\, so a \ combined with the first letter of ChucK file is mistaken for an escape character.

This error is only present on Windows as far as I can tell, it is not present on OSX.

EDIT: Turns out I'm incorrect about it not being present on OSX. Prefixing .\ when running ChucK from terminal does not work (and I suppose it shouldn't).

[ericheep]

Hmm, it seems it's this chunk in util_string.cpp that is the part of the issue, which only runs if there is a \ in the command.

if( s[i] == '\\' && (i+1) < s.length() )
{
    // check next char
    if( s[i+1] == ':' || s[i+1] == '\\' )
    {
        // add
        mask[i] = 1;
        // skip next character
        i++;
    }
    else
    {
        // error: recognized escape target
        fprintf( stderr, "[chuck]: unrecognized escape sequence: \\%c", s[i+1] );
        // return false
        ret = FALSE;
        // go clean
        goto done;
    }
}

It seems like we're stopping ChucK from loading a file if it encounters an escape sequence in the command, I'm unsure of how we can accommodate both loading a command with backslaches (for example, the command chuck C:\Users\eric\Desktop\test.ck will error out) and killing ChucK when it encounters an escape character. I'm also a bit unsure of the necessity of the latter, and I'm curious about its use case.

[spencersalazar]

This is actually a pretty big historical disaster area in ChucK and has been changed/redesigned/fixed several times in the face of competing priorities/demands.

Basically ChucK uses : as a separator for command line arguments to individual scripts (e.g. chuck test.ck:3:4:5 will supply 3, 4, and 5 as me.arg(0), me.arg(1) and me.arg(2) respectively). This creates a problem on Windows when filenames like e.g. c:\file.ck are parsed as running c.ck with the argument \file.ck.

It becomes even more fun when, on Windows, you want to run a script that takes a ChucK file passed as a command line argument and exports it to a WAV file passed as a command line argument. This is how miniAudicle Export works: by running as a subprocess e.g. chuck c:/Program Files/ChucK/scripts/export.ck:c\:/path/to/inputfile.ck:c\:/path/to/outputfile.wav. Its pretty nasty, but it works, and depends on a structured, reliable way to distinguish : used as part of a path or command line argument and : used as a command line argument separator. At some point we decided to use \ at the expense of Windows command line users, which were assumed to be few in number, to ensure reliability for Windows miniAudicle Export users, assumed to be many more in comparison.

chuck is still usable on the command line in Windows; you have to use / as a directory separator instead of \. They usually work interchangeably and few things will complain, though \ will be used by default for e.g. tab completion as you have noted. Unfortunately to change this it would have to be fairly clear that any proposed solution will still be able to work correctly with miniAudicle exporting, drive letters in file names, allow : characters to be included in command line arguments, and do all of these in ways that are not overly inconvenient or inconsistent on other platforms.

[ericheep]

From what you're saying, it seems that the only way correct this in a manner that would be acceptable on other platforms would be to change the method in which command line arguments are separated (e.g. using spaces instead of colons). But this big of a change doesn't sound likely without some considerable effort as well as a consensus from the ChucK community, so I won't pin my hopes on it.

The main driver for me on this issue was being able to run a ChucK shred from inside of an alternative IDE, and the manner in which a ChucK plugin would determine the path of the buffer was prohibiting that (as it would default to Windows type pathing), but there are workarounds for those issues.

[spencersalazar]

Alternative IDE support is probably a bigger priority than pure command line support, so if any other ideas come up that don't involve big user-facing changes, Im all ears.