Hi all Currently we are running a batch file on Windows that uses Putty's Plink to execute commands on a unix system. When I run these batch files from VisualWorks using WinProcess's executeCommand it hangs when it does the Plink command. I'm thinking of using an alternative to Plink but I haven't had much luck finding one. Help anyone? Regards,
012 671 8296
Even as love crowns you so shall he crucify you.
This email and all content are subject to the following disclaimer:
http://content.momentum.co.za/content/legal/disclaimer_email.htm
|
> Currently we are running a batch file on Windows that uses Putty's
> Plink to execute commands on a unix system. When I run these batch > files from VisualWorks using WinProcess's executeCommand it hangs > when it does the Plink command. > > I'm thinking of using an alternative to Plink but I haven't had > much luck finding one. In general I find that you will encounter less deadlocks if you use sockets from VW than if you use DLLCC or external processes. One solution along that line could be to use an SSH client to open a tunnel to the telnet service on the unix machine. Visualworks could then open a socket to the local side of the tunnel, detect and satisfy the login prompt. From there on you have a unix command line REPL available on your socket. R - |
In reply to this post by Nel, Dirk
On Feb 14, 2007, at 6:04, Nel, Dirk wrote:
I don't know if this is help or not... Michael Lucas Smith and friends at Wizard did some improvements to the WinProcess stuff recently and posted about it on the vw-dev channel. They published their work in the Open Repository as ExternalProcessStreams. So you might try using that and see if it improves your ability to work with plink. I've copied the contents of Michael's original message below the sig. HTH -- Travis Griggs Objologist "Only one thing is impossible for God: to find any sense in any copyright law on the planet." - Mark Twain " Hi, I've always wondered why the external process classes were hard wired to use a shell on different platforms. It dawned on me that those issues raised about the Unix installer requiring C-Shell may be related? If the only reason the unix installer needs C-Shell is so that Smalltalk can execute external processes - well, I have the answer to that published in Public Store now. ExternalProcessStreams This executes applications on Windows/Unix (mirroring the ExternalProcess hierarchy) but does so without involving a command-line shell. It gives you access to the read/write/error streams of the program you're running. If this is useful to integrate, it could potentially remove that pointless C-Shell dependency on Unix installations. Also, it removes the redundant access to cmd.exe which just gets in the way when you're trying to do serious in/out streaming with another application under Windows. The API is as follows: ExternalProcess execute: 'myprogram.exe' arguments: #() do: [:readStream :writeStream | ] errorStreamDo: [:errorStream | ] I hope this library helps - and big kudos goes to my colleague David Prices for figuring out the tricky Windows Pipe security calls. Cheers, Michael" |
Free forum by Nabble | Edit this page |