<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 6:21 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Again, if you say:<br>
<br>
(lldb) platform select remote-ios<br>
(lldb) target create ls<br>
<br>
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.<br></blockquote><div>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.  </div><div><br></div><div>I assume the codepath for handling "target create" already resolves the executable, otherwise more basic stuff would have already broken.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
> On Oct 14, 2014, at 6:06 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
> 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?<br>
<br>
</span>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".<br>
<span class=""><br>
> Maybe a better solution is to have RunShellCommand() call Platform::ResolveExecutable.<br>
<br>
</span>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.</blockquote><div>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.  </div></div></div></div>