It's not just file names, you would also have to make sure there's nothing else that might be in command argument or option value that has a single & a double quote, since without the backslashes this would be impossible.
If you really want to do this, I think it would be better to add a debugger setting for the "protection character". Then this would be set to something else (maybe "#") on Windows, and backslash on all other systems. That way you could probably always find a protection character that you could use for whatever gnarly string you ended up having to pass through the command interpreter. Jim > On Jan 8, 2015, at 2:55 PM, Zachary Turner <ztur...@google.com> wrote: > > Actually ' is a valid filename character in Windows, but not ". That being > said, it's so rare, and having a backslash is so common that I would prefer > the common case to be easy, and the rare case being either unsupported or > difficult is ok with me. So I'd still prefer to disable this backslash > handling on Windows for now, and then fix ' on Windows separately in the > future. > > On Thu Jan 08 2015 at 2:51:51 PM Zachary Turner <ztur...@google.com> wrote: > On Windows, that's not a valid file name, and in fact any file name that has > an escaped character is not a valid filename. I see what you're getting at > though, that for non-Windows it's necessary. Can I wrap the backslash > handling in #ifndef _WIN32 then? > > On Thu Jan 08 2015 at 2:49:49 PM <jing...@apple.com> wrote: > If I have a file called foo"bar'baz, how what would I put in the place of > <AWKWARD NAME> for > > (lldb) file <AWKWARD NAME> > > Right now, I can do: > > (lldb) file foo\"bar\'baz > Current executable set to 'foo"bar'baz' (x86_64). > > Jim > > > > On Jan 8, 2015, at 2:31 PM, Zachary Turner <ztur...@google.com> wrote: > > > > FWIW, Removing backslash handling from this function (essentially ignoring > > backslashes in command arguments) fixes about 12-15 tests on Windows with > > no other changes. I see there's some logic in Args for encoding and > > decoding escape sequences, but this only happens if a particular command > > option is set, and that command only only appears to be set for the > > "prompt" command. I'm not sure if removing the backslash logic from > > SetCommandString would interfere with this command in any way, but it > > doesn't seem like it would interfere with any other commands, unless I'm > > missing something. > > > > On Thu Jan 08 2015 at 1:43:16 PM Zachary Turner <ztur...@google.com> wrote: > > One thing causing many tests to fail on Windows is the presence of > > backslashes in argument. Until now, I've worked around this in many cases > > by making sure that arguments with backslashes are always quoted. > > > > But there are some cases where this is not easy to guarantee and now I'm > > leaning towards (at least on Windows) allowing backslashes in argument > > strings. The code in question comes from the function void > > SetCommandString (const char *command) in the file Args.cpp > > > > In particular, it implements special handling of whitespace, single quotes, > > double quotes, and backslashes. For the case of backslashes it removes > > them from the string. > > > > What would be the implications of removing backslash handling from this > > function for all platforms? I would prefer to keep platform specific code > > out of generic code, but I think this needs to be changed on Windows. > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
