Running a multiline shell command

[Mike Bonner]

I suspect the behavior you are seeing is because telnet acts like its own
shell process, and isn't displaying to stdout of the shell that starts it,
but rather is talking to itself. Unlike stuff like grep/etc that display to
stdout of the calling shell. Hence seeing the stuff before, and the stuff
after but not the stuff once the term connection happens. I think this can
be gotten around by opening telnet directly with shell, but then you run
into issues. Open process would probably work to run telnet but the
applescript definitely looks like its the easiest way.

On Mon, Dec 12, 2011 at 12:57 PM, Bob Sneidar <bobs at twft.com> wrote:

> Well I determined that whatever Livecode is using on a Mac is what the
> shell expects for newline characters. I determined this by manually
> replacing all newlines in the property inspector (where I keep the shell
> code) with whatever the return key produces. I then copied the value from
> the property editor and then pasted it into the terminal window. I got
> EXACTLY what I expected, that is, the output of the telnet session.
>
> HOWEVER... When I try to use the Livecode SHELL() to pass the property
> that way, the shell command returns:
>
> Connection closed by foreign host.
>
> The file contains:
>
> Trying 172.16.0.121...
> Connected to 172.16.0.121.
> Escape character is '^]'.
>
> This tells me that for whatever reason, everything that telnet is saying
> is NOT being sent to the file. The file gets everything before telnet kicks
> in, and the SHELL() function returns everything AFTER telnet exits, but
> everything between is hidden from the shell command.
>
> Now here is where things get interesting. I opened the applescript
> dictionary for terminal, and discovered they had a do script command.
> Hmmm... So I fiddled with the editor until I got an applescript that did
> essentially the same thing. I ran it, and lo and behold my text file output
> of my mac addresses appeared, amidst some garbled stuff, but then I can do
> lineoffsets and clean all that up fine.
>
> Next, I copied the successful code into my Livecode property, and instead
> of using the Livecode SHELL() command, I used do myScript as Applescript.
> Dammit if it didn't work just fine!!
>
> So then, I think this establishes that there is some kind of problem with
> the way the shell command interacts with the terminal. I would call this a
> bug, but I don't know enough about what is going on in the background to do
> so. It may be some kind of internal OS security issue, but then why would
> Applescript work fine doing essentially the same thing, which is telling
> the shell process to run a script?
>
> Anyway, I have a solution, and others may profit from what I have
> discovered. Here is the Applescript I produced:
>
> copy "telnet 172.16.0.121 >" & quote & "/Users/Shared/scanout.txt" & quote
> & return to theScript
> copy theScript & "theUser" & return to theScript
> copy theScript & "thePassword" & return to theScript
> copy theScript & "print " & quote & "show mac-address" & quote & return &
> return to theScript
> copy theScript & "exit" & return & "exit" & return to theScript
> copy theScript & "y" & return & "n" & return to theScript
>
> tell application "Terminal"
>        do script theScript
> end tell
>
> Before sending this I replace theUser and thePassword with the actual ones
> of course.
>
> Bob
>
>
> On Dec 10, 2011, at 4:53 AM, Bernard Devlin wrote:
>
> > Could it be an issue with the "return" character?  As you know, they are
> > different on each platform.  You could try variations between ascii 10
> and
> > 13.
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>