AutoHotkey Community

@floh:

Unfortunately I'm not too familiar with and not currently setup to test what you are trying to do. It sounds like the problem you may run ito would be sending data to the console application once it has started. The current version of CMDret has not been designed to interact with a running program. It has been designed to start a console application and retrieve the resulting output. The application should receive its params on startup and terminate when finished without additional user input.

thank you corrupt
It has been designed to start a console application and retrieve the resulting output.
this is the point. i have to keep open the session.[/i]

Chris, this is the way i tried first. It works but it is not the best way because the server can send nothing for minutes or hours and from one to the other second thousands of lines.

@ floh
have you checked if like the (unix) tail command line app, you can use a log which is created in parallel from its shell equivalent to trigger those events.

Sorry folks, I might have lost you here cause I havn't read the 5 pages of that thread. If the above has been said already, ignore my (therefore useless) comment. Thx.

for my application it's not a good idea to write a file and tail it (i know the tail command from linux). It is better to wait until cmdret is ready to solve my problem.

There weren't any plans to add that type of functionality to CMDret (unless I'm misunderstanding...) but it does sound like it might be useful... Would you mind listing specifically what functionality you would like CMDret to have. For example, how would you like to retrieve the changed data? output to a control? store in a variable? If you would like to perform an action based on values received would you need to send data to the console application while it is running? Do you need to attach to an application that is already running?, etc... Also, could you suggest a setup that I could use to test, based on what you would like CMDret to do?

all what i want is simply this:
open a SSH session to a server and make the output user friendly (GUI).
Tere are some other applications who need a feature to keep the app open such as nslookup on the command prompt (you can use this for testing). After you type nslookup a special prompt apears and wait for commands.
How to retrieve the data? in my opinion it should change a variable or a control. For sending data it may be useful to store them in a variable and call cmdret in a way that sends the data to the application.

My (simplyfied) idea how it should work:
1. open the application or DLL (CMDRET, open, <appname>)
2. interoperate as many as you want (CMDRET, send, <commands>)
3. close the application (CMDRET, close)

(sorry my english. my language is german)

@floh
Du bist aber nicht zufällig (LOTTOwahrscheinlichkeit) der Notepad2-Floh ?

Unfortunately 2 will likely not get added to CMDret. 1, 3 might work ok with the next version of the CMD version with using the AHK script to Send <commands>

Thanks for the suggestions

BoBo: Neeee Das ist irgend ein anderer. Ich bin es auf jeden Fall nicht.
Corrupt: thank you for your answer.

In same cases a simpler, pure AHK solution is sufficient.

Thanks . I'm not much of a fan of using the clipboard that way but it might be handy in some cases...

What is the problem with the clipboard (apart from the bookmarking and picture placeholder issues in word processing applications - which will be fixed someday)? If you want, you can save it before use and restore afterwards. Its use is brief (copy some text there and immediately get it to a normal AHK variable. In the few days I am playing with this method I did not see anything affected adversely. Did you?

I think the main issue is that the clipboard is not usually used to pass data for variables. Often the clipboard is a "dumping ground" for office applications, pictures, and scraps that people want to save.

There is also a security issue involved, because if you don't clear the contents of the clipboard, other applications or "others" may have access to the information that you put there.

Clearing the contents of the clipboard would appear to be a problem in itself because you obviously would want only a specific item cleared and may not want to interfere with other items in the clipboard that other applications have put.

If you are using the clipboard on only just your computer than this issue of data being sent to the clipboard and then passed to variables is not such a big deal, but suppose other people are using your script. Therefore, some user may be using Excel, Word, etc.. and copying and pasting items from the clipboard while your script is running. This may or may not cause a problem. If your script is checking for specific items in the clipboard, than it does not matter so much what other items are being copied to the clipboard too. If your script is copying data and then pasting it into a variable than I'm wondering if there could be a "collision" where the wrong/unexpected data gets copied to your script's variable or to a user that is using the clipboard and say Excel. From my experience of using the clipboard in such a manner, the odds seem very low that a "collision" will occur. But, still, there is the issue that you might not want your data to be sitting on the clipboard for some other user to paste or your script might clear data on the clipboard at the wrong time and while a user is using the clipboard.

I think, CMDret features, being built into AHK would bypass some of the issues with using the clipboard. But, until CMDret does become part of AHK than Laszlo's clipboard script solution can work in many situations. I think both solutions are useful.

It is true, this is why I wrote that in "some cases" the pure AHK solution is sufficient. You can save the clipboard just before use. The script overwrites its content with pure text, and immediately copies it into a variable, when you restore the clipboard to its original state. The clipboard (with its possibly needed content) is unavailable for less than 40 ms, which is shorter than a blink of the eye. If you run the console application completely in the background (with some modification of the example script), this might, very rarely, cause problems. However, if in this blackout time you pop up a message, that your console data is available, the user cannot initiate a clipboard transaction, so the probability of a conflict is even lower.

The worst case is probably different: if the user starts a huge clipboard copy or paste just before the console program terminates. It makes the clipboard unavailable for the console output script for a long time. It may time out, loosing the data.

I'm not sure how your copying the contents of the clipboard, let your script do what it wants, and then pasting the previous contents back would work. Are you saying paste the contents to a temporary file on the hard drive? If so, than this might slow the script down and there is also a security issue.

To be fair, I calculate the odds of a "clipboard collision" between a script and a user to be very low, but still its a possibility. I'm just curious about possible workarounds to minimize "clipboard collisions" as much as possible.

In your worse case... It also seems that you can have the script temporarily block user input just before the console program terminates to prevent this problem from occurring.

I think the worse case is more about what to do with existing user data that is on the clipboard, the user trying to copy new data to the clipboard while the script is running, and the user might wanting to use clipboard data while the script is running or after the clipboard was cleared. Again the odds of collision are very small, but....

I was thinking perhaps you could pass the original clipboard data into a variable too, like say variable "X". Then your script uses the clipboard. You then copy the contents of variable "X", back to the clipboard. At critical points of execution in which the users could interfere or copy new and unwanted data into the clipboard than you block user input.

Again, if you are using the script yourself, than its not an issue, but it will be on a script in which others (the more the higher the odds) are using and working on the computer at the same time or using the script over and over again.