Hi.
I decided to ask before I will try it. Best regards, Denis |
mmmm I don't know. Can you at least try for the first time in a 32 bits ARM ? On Fri, May 12, 2017 at 5:00 AM, Denis Kudriashov <[hidden email]> wrote:
|
I just checked. It works perfectly. One notice for API: OSSUnixSubprocess new command: '/bin/ls'; arguments: #('-la' '/Users'); redirectStdout; runAndWaitOnExitDo: [ :process :outString | outString ] Why you are not return result of block? It would be very handy (here it is an OSSUnixSubprocess instance). 2017-05-12 14:18 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
|
Little problem which I not understand. Maybe you can explain. Path '~' is not recognizied in ls command:
OSSUnixSubprocess new command: '/bin/ls'; arguments: #('~'); redirectStdout; runAndWaitOnExitDo: [ :process :outString | outString ] It returns empty string and console report:
Any idea why it not works properly? (from command line "ls ~" returns expected files). 2017-05-15 11:52 GMT+02:00 Denis Kudriashov <[hidden email]>:
|
Hi Denis, the ~ (tilde) is expanded by the shell, a running process should expand it. In the case of the command line tools they don't expand it, as they expect the shell to expand it before calling. Cheers, Pablo On Mon, May 15, 2017 at 12:01 PM, Denis Kudriashov <[hidden email]> wrote:
Pablo Tesone.
[hidden email] |
In reply to this post by Denis Kudriashov
On Monday 15 May 2017 03:31 PM, Denis Kudriashov wrote:
> > It returns empty string and console report: > > ls: cannot access ~: No such file or directory > > Any idea why it not works properly? (from command line "ls ~" returns > expected files). ~ is a shell language synonym for $HOME. Both are expanded by the shell before calling file syscall in the kernel. Kernel's filename resolver does not do ~ or $HOME expansions. Regards .. Subbu |
In reply to this post by tesonep@gmail.com
2017-05-15 12:10 GMT+02:00 [hidden email] <[hidden email]>:
Thank's Pablo |
In reply to this post by K K Subbu
2017-05-15 12:13 GMT+02:00 K K Subbu <[hidden email]>:
Thanks Subbu :) |
Denis, you can also have shortcut methods to call shell from OSSubprocess. See the tests under "tests - shell" protocol. Cheers, On Mon, May 15, 2017 at 8:00 AM, Denis Kudriashov <[hidden email]> wrote:
|
2017-05-15 14:04 GMT+02:00 Mariano Martinez Peck <[hidden email]>: Denis, you can also have shortcut methods to call shell from OSSubprocess. See the tests under "tests - shell" protocol. I tried this: OSSUnixSubprocess new shellCommand: 'ls ~'; redirectStdout; runAndWaitOnExitDo: [ :process :outString | ^outString ]. And it still returns empty string without error in console. With "ls ../" it works fine |
shellCommand: 'bash -c ''ls ~''';
|
On 15 May 2017 at 15:26, Eliot Miranda <[hidden email]> wrote:
But then that would run ls inside of bash inside of the system shell (/bin/sh), wouldn't it? What's the point? |
Hi Damien,
sh -c 'echo ~/$0' foo prints /Users/eliot/foo That may be useful. |
In reply to this post by Denis Kudriashov
On Monday 15 May 2017 05:46 PM, Denis Kudriashov wrote:
> OSSUnixSubprocess new > shellCommand: 'ls ~'; > redirectStdout; > runAndWaitOnExitDo: [ :process :outString | > ^outString > ]. What exactly are you trying to do? If you want the list of entries in ~ directory, you could use FileDirectory methods: (FileDirectory on: (OSProcess thisOSProcess environmentAt: 'HOME')) entries collect: [ :f | f name ]. Regards .. Subbu |
In reply to this post by Eliot Miranda-2
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 ~\"') On 15 May 2017 at 16:28, Eliot Miranda <[hidden email]> wrote:
|
On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
In reply to this post by K K Subbu
2017-05-15 16:55 GMT+02:00 K K Subbu <[hidden email]>:
My question was only about tilda usage. (FileDirectory is not exists in Pharo anymore. We moved to FileSystem project) |
> On 15 May 2017, at 18:03, Denis Kudriashov <[hidden email]> wrote: > > > 2017-05-15 16:55 GMT+02:00 K K Subbu <[hidden email]>: > What exactly are you trying to do? If you want the list of entries in ~ directory, you could use FileDirectory methods: > > (FileDirectory on: (OSProcess thisOSProcess environmentAt: 'HOME')) entries collect: [ :f | f name ]. > > My question was only about tilda usage. > (FileDirectory is not exists in Pharo anymore. We moved to FileSystem project) FileLocator home children |
In reply to this post by Eliot Miranda-2
On Mon, May 15, 2017 at 08:14:44AM -0700, Eliot Miranda wrote:
> > > On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <[hidden email]> 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. I'm not sure why Denis is having problems, but... OSSUnixSubprocess>>shellCommand: aShellCommandString "This is a simple facility method for the cases when the user wants to use shell as the program. This way, the user can directly send shellCommand: 'ls -la | grep Pharo > /tmp/test.txt ' with the whole string rather than having to do set the command sh, send the '-c' argument, etc etc etc. We first try to use the SHELL defined in the OS by getting the env variable $SHELL. If not found, then we fallback to /bin/sh" command := Smalltalk platform environment at: 'SHELL' ifAbsent: ['/bin/sh']. arguments := Array with: '-c' with: aShellCommandString. And if I execute the following in a playground: | ls | OSSUnixSubprocess new shellCommand: 'ls ~'; redirectStdout; runAndWaitOnExitDo: [ :process :outString | ls := outString ]. ls. It returns the expected value. Cheers, Alistair > On 15 May 2017 at 16:28, Eliot Miranda <[hidden email]> wrote: > > Hi Damien, > > On May 15, 2017, at 6:44 AM, Damien Pollet <[hidden email]> > wrote: > > > On 15 May 2017 at 15:26, Eliot Miranda <[hidden email]> > 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. |
On Mon, May 15, 2017 at 04:10:17PM +0000, Alistair Grant wrote:
> On Mon, May 15, 2017 at 08:14:44AM -0700, Eliot Miranda wrote: > > > > > > On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <[hidden email]> 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. > > I'm not sure why Denis is having problems, but... > > OSSUnixSubprocess>>shellCommand: aShellCommandString > "This is a simple facility method for the cases when the user wants to use shell as the program. > This way, the user can directly send > shellCommand: 'ls -la | grep Pharo > /tmp/test.txt ' with the whole string > rather than having to do set the command sh, send the '-c' argument, etc etc etc. > We first try to use the SHELL defined in the OS by getting the env variable $SHELL. > If not found, then we fallback to /bin/sh" > command := Smalltalk platform environment at: 'SHELL' ifAbsent: ['/bin/sh']. > arguments := Array with: '-c' with: aShellCommandString. > > > And if I execute the following in a playground: > > | ls | > OSSUnixSubprocess new > shellCommand: 'ls ~'; > redirectStdout; > runAndWaitOnExitDo: [ :process :outString | > ls := outString > ]. > ls. > > > It returns the expected value. One thought: Denis, are you using a non-English keyboard? Is there any chance that what you are entering looks like a tilda, but is some other unicode character? Maybe copy-and-paste the code I entered above? Cheers, Alistair > > On 15 May 2017 at 16:28, Eliot Miranda <[hidden email]> wrote: > > > > Hi Damien, > > > > On May 15, 2017, at 6:44 AM, Damien Pollet <[hidden email]> > > wrote: > > > > > > On 15 May 2017 at 15:26, Eliot Miranda <[hidden email]> > > 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. |
Free forum by Nabble | Edit this page |