Does OSSubprocess works on ARM vm?
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 <dionisiydk@gmail.com> wrote:
Hi.
I decided to ask before I will try it.
Best regards, Denis
-- Mariano http://marianopeck.wordpress.com
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 <marianopeck@gmail.com>:
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 <dionisiydk@gmail.com> wrote:
Hi.
I decided to ask before I will try it.
Best regards, Denis
-- Mariano http://marianopeck.wordpress.com
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: ls: cannot access ~: No such file or directory Any idea why it not works properly? (from command line "ls ~" returns expected files). 2017-05-15 11:52 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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 <marianopeck@gmail.com>:
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 <dionisiydk@gmail.com> wrote:
Hi.
I decided to ask before I will try it.
Best regards, Denis
-- Mariano http://marianopeck.wordpress.com
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. Check https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html and http://www.davidverhasselt.com/expanding-a-leading-tilde-in-cc/ Cheers, Pablo On Mon, May 15, 2017 at 12:01 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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:
ls: cannot access ~: No such file or directory
Any idea why it not works properly? (from command line "ls ~" returns expected files).
2017-05-15 11:52 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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 <marianopeck@gmail.com>:
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 <dionisiydk@gmail.com> wrote:
Hi.
I decided to ask before I will try it.
Best regards, Denis
-- Mariano http://marianopeck.wordpress.com
-- Pablo Tesone. tesonep@gmail.com
2017-05-15 12:10 GMT+02:00 tesonep@gmail.com <tesonep@gmail.com>:
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.
Check https://www.gnu.org/software/bash/manual/html_ node/Tilde-Expansion.html and http://www.davidverhasselt.com/expanding-a-leading-tilde-in-cc/
Thank's Pablo
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
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 <dionisiydk@gmail.com> wrote:
2017-05-15 12:13 GMT+02:00 K K Subbu <kksubbu.ml@gmail.com>:
~ 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.
Thanks Subbu :)
-- Mariano http://marianopeck.wordpress.com
2017-05-15 14:04 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com>:
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
On May 15, 2017, at 5:16 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-05-15 14:04 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com>:
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 ].
Try something like shellCommand: 'bash -c ''ls ~''';
And it still returns empty string without error in console. With "ls ../" it works fine
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Hi Damien,
On May 15, 2017, at 6:44 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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
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 <eliot.miranda@gmail.com> wrote:
Hi Damien,
On May 15, 2017, at 6:44 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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
On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <damien.pollet@gmail.com> 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 <eliot.miranda@gmail.com> wrote:
Hi Damien,
On May 15, 2017, at 6:44 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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
On Mon, May 15, 2017 at 08:14:44AM -0700, Eliot Miranda wrote:
On Mon, May 15, 2017 at 8:09 AM, Damien Pollet <damien.pollet@gmail.com> 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 <eliot.miranda@gmail.com> wrote:
Hi Damien,
On May 15, 2017, at 6:44 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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 <damien.pollet@gmail.com> 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 <eliot.miranda@gmail.com> wrote:
Hi Damien,
On May 15, 2017, at 6:44 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
On 15 May 2017 at 15:26, Eliot Miranda <eliot.miranda@gmail.com> 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.
2017-05-15 18:10 GMT+02:00 Alistair Grant <akgrant0710@gmail.com>:
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.
Yes, it works for me too on Mac. Maybe I did something wrong on Raspberry. I will check tomorrow. Thank's for help
2017-05-15 22:19 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
2017-05-15 18:10 GMT+02:00 Alistair Grant <akgrant0710@gmail.com>:
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.
Yes, it works for me too on Mac. Maybe I did something wrong on Raspberry. I will check tomorrow.
I checked again. It not works on Raspberry same way: empty string returns. Not know how it would be on other Linux
On Tuesday 16 May 2017 04:26 PM, Denis Kudriashov wrote:
I checked again. It not works on Raspberry same way: empty string returns. Not know how it would be on other Linux
If you run it from command line, does it list the files on the tty? Then it could be a bug in redirectStdout method. HTH .. Subbu
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
2017-05-15 16:55 GMT+02:00 K K Subbu <kksubbu.ml@gmail.com>:
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)
On 15 May 2017, at 18:03, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-05-15 16:55 GMT+02:00 K K Subbu <kksubbu.ml@gmail.com>: 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
participants (8)
-
Alistair Grant -
Damien Pollet -
Denis Kudriashov -
Eliot Miranda -
K K Subbu -
Mariano Martinez Peck -
Sven Van Caekenberghe -
tesonep＠gmail.com