[lldb-dev] Backslashes in command arguments
zturner at google.com
Mon Jan 12 14:05:10 PST 2015
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.
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.
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?
On Thu Jan 08 2015 at 3:00:30 PM <jingham at apple.com> wrote:
> 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.
> > On Jan 8, 2015, at 2:55 PM, Zachary Turner <zturner at 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 <zturner at google.com>
> > 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 <jingham at 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 <zturner at 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 <zturner at google.com>
> > > 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 at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev