Eliot Miranda-2 wrote

OSP is an interface to exec.

That's good to know. Thanks.

I investigated further and accidentally found out that it wasn't the multi-line part at all that was the problem. It was that my string contained an ellipsis, which forced the argument to waitForCommand: into a WideString. Is there a workaround? can OSP only handle ByteStrings?

Thanks. Sean

-- View this message in context: http://forum.world.st/OSProcess-and-multiline-input-tp4418726p4418945.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

David T. Lewis wrote

I have a hunch that if you were to convert your multi-byte input string into a byte array, thence back to a string of 8-bit characters

I tried aWideString asByteArray asString (as well as some other experiments), which did not work. Is that what you meant?

Thanks. Sean

-- View this message in context: http://forum.world.st/OSProcess-and-multiline-input-tp4418726p4426766.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

On Fri, Feb 24, 2012 at 02:00:12PM -0800, Eliot Miranda wrote:

On Fri, Feb 24, 2012 at 1:53 PM, Sean P. DeNigris sean@clipperadams.comwrote:

...

I'm trying to pass a multiline argument, but none of the things that work in the shell seem to work with OSP.

I passed both of the following to PipeableOSProcess>>waitForCommand: with a "No such file or directory" error, which usually means that the multiline part was not processed correctly. However, if I copy/paste them into the shell, they work fine

heredoc: '/usr/bin/osascript -ss <<-EOF tell application "Safari" to activate tell application "Terminal" to activate EOF'

double-quoted string: '/usr/bin/osascript -ss -e " tell application "Safari" to activate tell application "Terminal" to activate"'

Why are these not working?

OSP is not a shell. Ask yourself what a program receives when iyt is invoked with the two examples above. Then provide the equivalent argument to OSP and you'll find it'll work. OSP is an interface to exec. A shell is an interface to exec. OSP doesn't parse arguments, just passes them onto exec. A shell does parse arguments before passing them onto exec. So the shell input

" tell application "Safari" to activate tell application "Terminal" to activate"

is a string argument which in Smalltalk would be written

(String with: Character lf), 'tell application "Safari" to activate', (String with: Character lf), 'tell application "Terminal" to activate'

Exactly so. PipeableOSProcess class>>command: will take the string you provide and pass it directly to a unix shell (/bin/sh which in most cases is a link to bash). It will exec that /bin/sh program, providing your input string directly to /bin/sh for processing. In turn, /bin/sh does its normal processing, and executes whatever programs you asked it to run. This means that the string you provide as input should contain exactly the characters that you would have typed on a keyboard and sent through the terminal driver to the /bin/sh program. Any <cr> or <lf> characters, quote marks, and so forth in the the string are passed directly to the /bin/sh program, which is the program that actually executes your command.

This may seem confusing if you are trying to send multiple lines of text to the shell, because the "multiple lines" are really just a string with some <cr> or <lf> characters embedded. You think of them as lines of text because the unix terminal driver handling your keyboard processes them that way; it waits until you hit your "enter" key before passing a line of input to the shell. But from the point of view of the shell, it is just a stream of bytes being sent to the shell, and by convention the shell treats a bunch of characters ending with a <lf> as a line of input.

Of course it is possible to handle a lot of this input parsing in Smalltalk, and that is what the classes in package CommandShell do. This allows you to do the input parsing directly without the assistance of a unix /bin/sh program. In other words, in your example we would separate the lines of input text, parse each line to interpret the tokens and expand file names as if we were a unix shell, and then directly invoke each individual program in each command line without the assistance of a real unix shell. And because each program that you run ends with an exit status code that it provides to the shell, we can make use of that exit status in Smalltalk, and do some conditional processing just as might be done by the real /bin/sh program.

Dave