There doesn't seem to be a good way to get access to the Debugger object from the Args class.  I tried changing Args to take a Debugger to its constructor, but it seems this isn't always possible, for example with anything having to do with OptionValue.<br><div><br></div><div>I could provide a default value of NULL for the Debugger, and if NULL it would fall back to the default escape character, but this seems awkward.</div><div><br></div><div>Since I've declared this as a global property, why should I even need a Debugger instance?  Shouldn't the global settings be static on the Debugger so that they can be accessed without an instance?</div><br><div class="gmail_quote">On Thu Jan 08 2015 at 3:00:30 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Jim<br>
<br>
<br>
> On Jan 8, 2015, at 2:55 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> On Thu Jan 08 2015 at 2:51:51 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> 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?<br>
><br>
> On Thu Jan 08 2015 at 2:49:49 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> If I have a file called foo"bar'baz, how what would I put in the place of <AWKWARD NAME> for<br>
><br>
> (lldb) file <AWKWARD NAME><br>
><br>
> Right now, I can do:<br>
><br>
> (lldb) file foo\"bar\'baz<br>
> Current executable set to 'foo"bar'baz' (x86_64).<br>
><br>
> Jim<br>
><br>
><br>
> > On Jan 8, 2015, at 2:31 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
> > On Thu Jan 08 2015 at 1:43:16 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> > 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.<br>
> ><br>
> > 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<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> > ______________________________<u></u>_________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
><br>
<br>
</blockquote></div>