[lldb-dev] Should FileSpec::Resolve() look at PATH?

[Zachary Turner]

On Tue, Oct 14, 2014 at 6:21 PM, Greg Clayton <gclayton at apple.com> wrote:

> Again, if you say:
>
> (lldb) platform select remote-ios
> (lldb) target create ls
>
> I would expect it to find it in the iOS SDK, not in /bin/ls. So the
> currently selected platform is the one that must resolve this.
>
Right but this is just target create, which is a different codepath than
Host::RunShellExecutable.  I'm not clear on all the use cases of
Host::RunShellCommand aside from that it runs as part of the test suite,
but I can search for it all tomorrow.  The point is that right
now, RunShellCommand is hard-coded to use /bin/ls.  It doesn't resolve
anything using any platform.

I assume the codepath for handling "target create" already resolves the
executable, otherwise more basic stuff would have already broken.


>
>
> > On Oct 14, 2014, at 6:06 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > Although extremely uncommon, it's theoretically possible to have a
> different system installation directory.  Is this not possible on posix
> platforms?  Is it guaranteed that /bin/sh is always the path, no matter
> what strange things a user might have done to their system?
>
> Yes this is possible. This is why you want the platform to resolve this.
> It can look at the environment for the current host platform if it is the
> host platform and "do the right thing".
>
> > Maybe a better solution is to have RunShellCommand() call
> Platform::ResolveExecutable.
>
> That isn't required, maybe for windows? But if this the current platform
> is the host platform, then running a command like "sh foo.cmd" should find
> the "sh" in the current path.

See first comment of this response.  If it's possible that sh is not in
/bin, as you've said, then isn't it a bug that LLDB_DEFAULT_SHELL is
hardcoded to /bin/sh?  If that's the case, then it seems to make sense to
change this to  simply "sh", and then have Host::RunShellCommand call
Platform::ResolveExecutable for all platforms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141014/2bdf88fd/attachment.html>