On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <[email protected]> wrote:
> My point was, if #shellCommand: accepts a single string for a whole > command, then surely it passes it to a system shell already, so why nest a > bash in between? (effectively running the equivalent of sh -c "bash -c \"ls > ~\"') > Clearly it doesn't do that otherwise Denis wouldn't have found that tile was unexpanded. I agree with you that it should. shellCommand: feels like a misnomer otherwise. > > On 15 May 2017 at 16:28, Eliot Miranda <[email protected]> wrote: > >> Hi Damien, >> >> On May 15, 2017, at 6:44 AM, Damien Pollet <[email protected]> >> wrote: >> >> On 15 May 2017 at 15:26, Eliot Miranda <[email protected]> wrote: >> >>> Try something like >>> >>> shellCommand: 'bash -c ''ls ~'''; >>> >> >> But then that would run ls inside of bash inside of the system shell >> (/bin/sh), wouldn't it? What's the point? >> >> >> -c's argument is parsed by the shell so one gets full expansion. >> Further, if there are arguments after the string, they are assigned to the >> positional parameters, so that >> >> sh -c 'echo ~/$0' foo >> >> prints /Users/eliot/foo >> >> That may be useful. >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- _,,,^..^,,,_ best, Eliot
