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

[Zachary Turner]

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?

Maybe a better solution is to have RunShellCommand() call
Platform::ResolveExecutable.

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

> As a follow up, the Platform::ResolveExecutable() should be the one to
> resolve executables and the function call actually shouldn't go on FileSpec.
>
> > On Oct 14, 2014, at 5:38 PM, Greg Clayton <gclayton at apple.com> wrote:
> >
> >
> >> On Oct 14, 2014, at 4:36 PM, Zachary Turner <zturner at google.com> wrote:
> >>
> >> I have an issue on Windows when trying to run shell commands.  We
> specify the shell as "cmd.exe", create a FileSpec out of this, and call
> FileSpec::Resolve.  This ends up making an absolute path out of cmd.exe,
> but it does so by just sticking the working directory onto the front of it,
> which is obviously wrong.
> >>
> >> My question is: For FileSpecs that are only filenames, nothing else,
> should we attempt to locate a matching file in PATH, and when we find one
> use the resulting absolute path?
> >
> > Not by default. We should have a method on FileSpec that might say
> "ResolveExecutableUsingPath()", but I wouldn't do it by default for every
> file spec. Not every file is an executable, so we shouldn't treat all files
> as executables by default unless a method is explicitly called on that.
> >
> > As a side questions, we provide a complete path to "/bin/sh" as the
> shell for unix, shouldn't we specify a full path to "cmd.exe" as well? Does
> it live in a known location on windows?
> >
> > Greg
> >
> >
> > _______________________________________________
> > 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...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141014/5dd66809/attachment.html>