Expect Library
-
Has anyone used this library in order to control a command prompt from their application? I need to find a tool that will enable my application to run a command that is passed from another application. The trick is that the command may be something that needs additional input. For example, App A could call my app (App B) and tell it to run a command-line utility that requires a logon. My app would need to pass back exactly what a user would see in a command window so that App B can send additional information. I'm told that the Expect library does this and wanted to know if anyone here has used it and can confirm that. Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe -
Has anyone used this library in order to control a command prompt from their application? I need to find a tool that will enable my application to run a command that is passed from another application. The trick is that the command may be something that needs additional input. For example, App A could call my app (App B) and tell it to run a command-line utility that requires a logon. My app would need to pass back exactly what a user would see in a command window so that App B can send additional information. I'm told that the Expect library does this and wanted to know if anyone here has used it and can confirm that. Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. RoweExpect works wonderfully on Unix and I have used it to be called from Shell Scripts to log on to remote server and execute commands on the server interactively. It is more of a network based tool/library and what you seem to be doing is an IPC kind of application. I doubt if it would work for your scenario. However I developed a similar app as yours where an old command line program was controlled via an MFC app. If you are trying to do the same, then there is a MSDN article that talks about how to do this and I found my solution based on that. I cant remember the title as it was several years ago. If you really need it, let me know and I will it dig it up. Good Luck.
-
Expect works wonderfully on Unix and I have used it to be called from Shell Scripts to log on to remote server and execute commands on the server interactively. It is more of a network based tool/library and what you seem to be doing is an IPC kind of application. I doubt if it would work for your scenario. However I developed a similar app as yours where an old command line program was controlled via an MFC app. If you are trying to do the same, then there is a MSDN article that talks about how to do this and I found my solution based on that. I cant remember the title as it was several years ago. If you really need it, let me know and I will it dig it up. Good Luck.
[krisko] Expect works wonderfully on Unix and I have used it to be called from Shell Scripts to log on to remote server and execute commands on the server interactively. [Tom] Yep. The Unix guys on a current job were the ones that recommended me looking at it. However, they're not Windows guys - hence my reason for being on the project :) - so they weren't sure if it would work from my code. [krisko] It is more of a network based tool/library and what you seem to be doing is an IPC kind of application. [Tom] In a nutshell. The Unix client will send my app (a Windows Service) a request to run a command-line program. I need to report back to the client what's transpiring with the request - whether the prog completed, if I'm back at the prompt, what's on the screen, etc. Does this sound like Expect will work or your code or the MSDN article? And I **badly** need it :) I'm not a rich man, but can send you some books :) Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe -
[krisko] Expect works wonderfully on Unix and I have used it to be called from Shell Scripts to log on to remote server and execute commands on the server interactively. [Tom] Yep. The Unix guys on a current job were the ones that recommended me looking at it. However, they're not Windows guys - hence my reason for being on the project :) - so they weren't sure if it would work from my code. [krisko] It is more of a network based tool/library and what you seem to be doing is an IPC kind of application. [Tom] In a nutshell. The Unix client will send my app (a Windows Service) a request to run a command-line program. I need to report back to the client what's transpiring with the request - whether the prog completed, if I'm back at the prompt, what's on the screen, etc. Does this sound like Expect will work or your code or the MSDN article? And I **badly** need it :) I'm not a rich man, but can send you some books :) Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. RoweIf it is a Unix client (assuming C/C++/Perl/Shell Script), it should be easy to use the Expect API within the client program itself to invoke a telnet session to a Windows Server. However this assumes that the program(yours) running on the Windows server should be a command line program and can be executed via a telnet session on the Windows Server, then Expect would be a good bet. However if it has to go through the Windows Service then I think you will have to spawn a child process and control its Read/Write handles from your service and finally return the output to the Unix client. I am assuming the communication b/w your Windows Service and the Unix Client is Sockets. A quick search yielded this and the idea I used is the pretty much the same for my project
-
If it is a Unix client (assuming C/C++/Perl/Shell Script), it should be easy to use the Expect API within the client program itself to invoke a telnet session to a Windows Server. However this assumes that the program(yours) running on the Windows server should be a command line program and can be executed via a telnet session on the Windows Server, then Expect would be a good bet. However if it has to go through the Windows Service then I think you will have to spawn a child process and control its Read/Write handles from your service and finally return the output to the Unix client. I am assuming the communication b/w your Windows Service and the Unix Client is Sockets. A quick search yielded this and the idea I used is the pretty much the same for my project
Oops there was a formatting error. Here is the link once again http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating\_a\_child\_process\_with\_redirected\_input\_and\_output.asp
-
Has anyone used this library in order to control a command prompt from their application? I need to find a tool that will enable my application to run a command that is passed from another application. The trick is that the command may be something that needs additional input. For example, App A could call my app (App B) and tell it to run a command-line utility that requires a logon. My app would need to pass back exactly what a user would see in a command window so that App B can send additional information. I'm told that the Expect library does this and wanted to know if anyone here has used it and can confirm that. Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe[, char *envp[ ] ] ] ); The types for argc and argv are defined by the language. The names argc, argv, and envp are traditional, but are not required by the compiler. See Argument Definitions for more information and for an example. Alternatively, the main and wmain functions can be declared as returning void (no return value). If you declare main or wmain as returning void, you cannot return an exit code to the parent process or operating system using a return statement; to return an exit code when main or wmain is declared as void, you must use the exit function. -
[, char *envp[ ] ] ] ); The types for argc and argv are defined by the language. The names argc, argv, and envp are traditional, but are not required by the compiler. See Argument Definitions for more information and for an example. Alternatively, the main and wmain functions can be declared as returning void (no return value). If you declare main or wmain as returning void, you cannot return an exit code to the parent process or operating system using a return statement; to return an exit code when main or wmain is declared as void, you must use the exit function.
WTF? :wtf:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
WTF? :wtf:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Any C (C++) programme accepts command line arguements - that's the 'argv, argc' in main() - what you do with them is up to you...
I know that, but WTF did that have to do with his question?
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
I know that, but WTF did that have to do with his question?
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
[, char *envp[ ] ] ] ); The types for argc and argv are defined by the language. The names argc, argv, and envp are traditional, but are not required by the compiler. See Argument Definitions for more information and for an example. Alternatively, the main and wmain functions can be declared as returning void (no return value). If you declare main or wmain as returning void, you cannot return an exit code to the parent process or operating system using a return statement; to return an exit code when main or wmain is declared as void, you must use the exit function.
trelliot wrote: A special function called main is the starting point of execution for all C and C++ programs. The main function is not predefined by the compiler; rather, it must be supplied in the program text. The declaration syntax for main is: [...snipped...][...snipped...][...snipped...] as void, you must use the exit function. :wtf: Why explain this to the guy who wrote Visual C++ Bible?
-
[, char *envp[ ] ] ] ); The types for argc and argv are defined by the language. The names argc, argv, and envp are traditional, but are not required by the compiler. See Argument Definitions for more information and for an example. Alternatively, the main and wmain functions can be declared as returning void (no return value). If you declare main or wmain as returning void, you cannot return an exit code to the parent process or operating system using a return statement; to return an exit code when main or wmain is declared as void, you must use the exit function.
-
Oops there was a formatting error. Here is the link once again http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating\_a\_child\_process\_with\_redirected\_input\_and\_output.asp
click click[^] -- An eye for an eye will only make the world blind.
-
trelliot wrote: A special function called main is the starting point of execution for all C and C++ programs. The main function is not predefined by the compiler; rather, it must be supplied in the program text. The declaration syntax for main is: [...snipped...][...snipped...][...snipped...] as void, you must use the exit function. :wtf: Why explain this to the guy who wrote Visual C++ Bible?
Nishant Sivakumar wrote: Why explain this to the guy who wrote Visual C++ Bible? I thought it was rather funny.
My: Blog | Photos WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
-
Nishant Sivakumar wrote: Why explain this to the guy who wrote Visual C++ Bible? I thought it was rather funny.
My: Blog | Photos WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
Colin Angus Mackay wrote: I thought it was rather funny. Me too. :-D I was actually visualizing Tom's face as he read the post (or the email). Vikram.
http://www.geocities.com/vpunathambekar "It's like hitting water with your fist. There's all sorts of motion and noise at impact, and no impression left whatsoever shortly thereafter." — gantww.
-
Colin Angus Mackay wrote: I thought it was rather funny. Me too. :-D I was actually visualizing Tom's face as he read the post (or the email). Vikram.
http://www.geocities.com/vpunathambekar "It's like hitting water with your fist. There's all sorts of motion and noise at impact, and no impression left whatsoever shortly thereafter." — gantww.
:-D I was just like "Oooooo kay" I just figured he/she didn't understand the question or was joking around with me. Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe -
[, char *envp[ ] ] ] ); The types for argc and argv are defined by the language. The names argc, argv, and envp are traditional, but are not required by the compiler. See Argument Definitions for more information and for an example. Alternatively, the main and wmain functions can be declared as returning void (no return value). If you declare main or wmain as returning void, you cannot return an exit code to the parent process or operating system using a return statement; to return an exit code when main or wmain is declared as void, you must use the exit function.
I appreciate the reply, but that problem isn't one of passing params to a command processor. The problem is interacting with the processor - especially in cases where a command-line app hasn't finished processing, but has requested more info. Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe -
If it is a Unix client (assuming C/C++/Perl/Shell Script), it should be easy to use the Expect API within the client program itself to invoke a telnet session to a Windows Server. However this assumes that the program(yours) running on the Windows server should be a command line program and can be executed via a telnet session on the Windows Server, then Expect would be a good bet. However if it has to go through the Windows Service then I think you will have to spawn a child process and control its Read/Write handles from your service and finally return the output to the Unix client. I am assuming the communication b/w your Windows Service and the Unix Client is Sockets. A quick search yielded this and the idea I used is the pretty much the same for my project
Sorry. Got sidetracked on other tasks with re: to the same app. The Windows Service must be in control of the entire thing. IOW, the Unix client will send commands to the Service to run. The Service will run the command and send results back to the client. A command might return to the prompt or it might not (as in the case of a command line app such as ftp or telnet) and I'll need to interactively send whatever the app displays back to teh client. Does this sound like Expect for Windows would work for me? Cheers, Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe