Share the finished AutoHotkey v2 Scripts and libraries you made here. Please put the current version of AutoHotkey v2 you used in Square Brackets at the start of the topic title.
Fixed potential security vulernability using mode "m" (WriteConsoleInput) - now StdIn is secure, and it can only communicate with the script, much more difficult to hijack.
Removed .ConsoleSend() method, because this contributed to a less secure background CLI session.
Added parameters to separate the environment from the commands, when calling cli.New().
Pure PowerShell now works with CliSAK.
- Known issue: multi-line commands not currently possible.
- Once you enter multi-line command mode you can't get out of it unless you terminate the session.
- Multi-line commands might be possible in mode "m" but still with some limitations.
Default environment is CMD window with /Q for ECHO OFF.
Removed most of the modes - now this cli class is "streaming only".
Updated CliData() wrapper function for one-time easy "run and collect". This is the equivalent of the old "w" (wait) mode.
Now using a callback only requires that the callback function exists.
Improved timing and execution of PromptCallback() - StdErr and StdOut easily line up within this callback function.
Added CliObj.ready property to indicate when the environment is finished loading and the first prompt is displayed.
- Best used in PromptCallback().
Added CliObj.BatchProgress property so the user can check which command in a multi-line set of commands is finished executing.
- Best used in PromptCallback().
Mode "m" now allows StdErr to be a separate stream (using mode "x").
- This can cause unwanted side effects with some programs, ie. the program may appear to hang.
Updated and simplified examples.
Added example GIF of wget Example #8.
Update:2020/11/12
* Fixed improper placement of CRLF when re-attaching the prompt.
Update:2020/10/23
Very minor update: Previous changes required the user to start command line commands with "cmd ...". This is no longer required. While limiting, it was easier to ensure success when running commands. Now that this limitation is removed the user must ensure care is taken to execute commands in a way that will succeed and must know what happens when running a particular program without the CMD shell.
Update:2020/09/28
Improved consistency of operation across modes, optimized code
Added QuitStringCallback() for user defined quit string.
Fixed handling of ADB environment. Prompt consistently shown after command execution.
Finished documentation comments (top of the script).
Added ConsoleSend() method for proper usage of StdIn using mode "m" (thanks @lexikos!)
Added GetLastLine(str) method for usage in callbacks to filter output.
Update:2020/07/31
Uploaded changes for AHK v2-a119
moved v2 version to v2 forum
Update:2020/05/26
added CLI object as parameters to callback functions
.output has been renamed to .stdout
.error has been renamed to .stderr
now when using stdout / stderr callback functions .stdout and .stderr will continue to accumulate so you can check or clear these values as needed
examples have been updated to reflect the changes
OP updated to show current list of prompts / shells supported with cliPromptCallback() function
Update: 2020/05/24
add mode f to filter control codes from SSH prompt
added prompt detection for SSH prompt
Update: 2020/05/20
moved to GitHub
cleaned up help comments in library
finally released AHKv2 version!
Update: 2020/02/06
Improved mode "m" to allow batch commands.
Fixed mode "m" handling of FreeConsole and AttachConsole when sending CTRL signals
(myObj.CtrlC() would kill the script in some cases)
Improved batch command handling in mode "b" and "m"
StdOutCallback() function recieves "__Batch Finished__" when complete
Details of their contributions are in the comments of the CLI class library. They have done a LOT. Without their contributions, I would not have gained the knowledge or the means to make this.
I'm happy to hear any commets/critiques to make this library more useful, fast, and memory-efficient.
Last edited by TheArkive on 01 Dec 2020, 11:30, edited 12 times in total.
Thanks @burque505
Fortunately not much as changed with all the alpha updates (that i know of) ... i haven't managed to test much more than the examples lately. I have some bigger projects that will put this library to the test.
Fixed potential security vulernability using mode "m" (WriteConsoleInput) - now StdIn is secure, and it can only communicate with the script, much more difficult to hijack.
Removed .ConsoleSend() method, because this contributed to a less secure background CLI session.
Added parameters to separate the environment from the commands, when calling cli.New().
Pure PowerShell now works with CliSAK.
- Known issue: multi-line commands not currently possible.
- Once you enter multi-line command mode you can't get out of it unless you terminate the session.
- Multi-line commands might be possible in mode "m" but still with some limitations.
Default environment is CMD window with /Q for ECHO OFF.
Removed most of the modes - now this cli class is "streaming only".
Updated CliData() wrapper function for one-time easy "run and collect". This is the equivalent of the old "w" (wait) mode.
Now using a callback only requires that the callback function exists.
Improved timing and execution of PromptCallback() - StdErr and StdOut easily line up within this callback function.
Added CliObj.ready property to indicate when the environment is finished loading and the first prompt is displayed.
- Best used in PromptCallback().
Added CliObj.BatchProgress property so the user can check which command in a multi-line set of commands is finished executing.
- Best used in PromptCallback().
Mode "m" now allows StdErr to be a separate stream (using mode "x").
- This can cause unwanted side effects with some programs, ie. the program may appear to hang.
I have a question, i have to made a telnet session to a device, how i can get it to work with your class? If i insert "telnet" into the environment param i get the command line input field as a multi line input so i cannot send the commands to the console. And it also does not load the telnet cleint. I installed the telnet via windows features. It would be nice if somebody could help me out.
@CappuccinoCake
please post your script so I can see what you are working with. How you use the PromptCallback() and StdOutCallback() functions is critical to making this work.
@CappuccinoCake
I have seen something like this before with ssh.exe on Windows 10, but you actually get an error message. I'm afraid I'll have to do more testing.
I tried using mode "m", and i saw that telnet does load, but immediately exits. There are strange side effects with some command line programs when redirecting stdout/stdin away from the console.
What kind of automation are you trying to accomplish? Maybe there is another way?
I have done more testing with putty/plink. That works quite well with CliSAK.
Please let me know if you find a success method. I may need to modify some settings when using CreateProcess DllCall().
I might actually add a mode for redirecting to file, so that the same interface (this script) can be used. I've tried file redirect with ssh.exe on Win10 and it does work, so that may be the solution for telnet (I've been trying to avoid using a file as much as possible).
Either I need to use a specific security descriptor or this isn't meant to work without a console. In which case, redirecting to a file would probably be the only option, but then your harddrive is constantly churning as the script keeps checking the file... definitely not ideal.
Or you can check out my socket script class, and write a telnet script. Main problem though, it's just sockets, no encryption.
EDIT:
Or you can use a modified version of mode "m", which i removed because it is a bit unsecure and could be hijacked by another application. The AHK v1 version currently uses this other method to execute mode "m". Basically it a typical hidden console that you can scrape, and send keystrokes to. But still not ideal because for decent performance you need to shrink the console size, which also reduces your ability to scroll back.
I think for the time being, I'm just going to take off telnet as a capability since I have found a few posts already of people being unable to use telnet with CreateProcess. I had added it as a capability only because i added the "prompt recognition" so it could be used with CliSAK. Never thought it would actually fail though.
Sorry to say, I think telnet and CliSAK won't be getting along any time soon.
EDIT2:
@CappuccinoCake
I might dabble with making my own telnet script using sockets. If i get one working I'll post it in the AHK v2 Scripts forum.
Sorry, i was not respomnding here because I had to do other stuff. I changed the line where you are sending multiple command to the normal telnet command only and the console isn't showing anithing...
If (IsObject(c))
c.close(), c:=""
oGui["CmdOutput"].Value := ""
batch := "ECHO. & telnet`r`n"
; Mode "r" removes prompt and command from data, so only output is visible.
c := cli.New(batch,"mode:|ID:Console_Streaming") ; Only using StdOutCallback()
@CappuccinoCake
Please read my previous post more carefully, as well as the comments in the main class script, specifically the option showWindow. Normally the console screen will be blank, because StdOut / StdIn / StdErr are redirected.
I'm afraid I mentioned Telnet as a possibility prematurely (I apologize for this). Other scripters / programmers have run into issues trying to run telnet and redirecting std handles. It would be more effective to rewrite Telnet in AHK using the socket class. Again, please read my last post. All is explained there.
EDIT:
I'm am planning to attempt to write a Telnet script that will recreate the protocol of the Telnet program, but I can't give a proposed ETA at this time.
Download on GitHub
... if you do any in-depth testing and find any issues please let me know
Better and better!