What is the difference between cscript and wscript? Which is best for doing Telnet and FTP automation in Windows?
In Windows, an executable is either a console application or a Windows application (or a SFU or Native application, but that doesn't matter here).
The kernel checks a flag in the executable to determine which.
When starting using CreateProcess WinAPI function, if it is a console application, the kernel will create a console window for it if the parent process doesn't have one, and attach the STDIN, STDOUT and STDERR streams to the console.
If it is a Windows application, no console will be created and STDIN, STDOUT and STDERR will be closed by default.
WSCRIPT.EXE and CSCRIPT.EXE are almost exactly identical, except that one is flagged as a windows application and the other is flagged as a console application (Guess which way around!).
So the answer is: If you want your script to have a console window, use CSCRIPT.EXE. If you want it to NOT have a console window, use WSCRIPT.EXE.
This also affects some behaviors, such as the WScript.Echo command. In a CSCRIPT.EXE this writes a line to the console window. In WSCRIPT.EXE it shows a messagebox.
For your application I suggest CSCRIPT.EXE. I think you should also look at PuTTY and PLink, and you should also see this here:
Capturing output from WshShell.Exec using Windows Script Host
Related
I am writing a service program which is expected to run in background. On Windows it will open a console window when run. I want it to go to background directly without that console window, so I used the -ldconf "-H=windowsgui" option, which worked as expected.
However, there is a catch. The program has a command line option -help, which output command line usage in the console. If I use -H=windowsgui, the help text is NOT printed even I start it in cmd.exe prompt.
It seems that the windowsgui option is not what I want. Is there anyway that the -help still works at commant line, and the console window will not persist if the program runs normally. I do not care if there is a console window pops up, provided that it disappears shortly without user intervention. i.e. I want a way on windows which is similar to the & operator on Linux.
P.S. if provided solution uses any other tools, I want that tool to be a Windows component, not any 3rd-party program. Thanks.
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
So I've done some digging to try and find a way to run a script in the background on startup. The only solution I've found is to use:
Set WinScriptHost = Nothing
Is this a reasonable way to do it? Or could it cause some issues? I mean, from what I can tell, it just stops WinScriptHost from being used to refer to an object. But I feel like that could cause trouble in some scripts. So, should I avoid using this method and do something else?
Thanks!
CScript is for console windows, consoles programs by their definitions have a console. WScript is for GUI programs, unlike console programs, windows are optional (although almost all programs will create a hidden main window if not creating a visible window, as windows are how Windows communicates with a program).
Using WshShell.Run, which has a window style parameter, you can run cmd hidden eg cmd /c cscript script.vbs.
When I have a Win32 non-console application (AFAIK, the console-ness of a Win32 app is linked into the exe), starting it from the console cmd.exe will return to the command prompt immediately, running the application "in the background" (o.c. it can have a GUI of sorts, or even open its own console window)
Is it possible in the non-console executable to detect that it was launched from cmd.exe and "attach" it to the launching cmd.exe?
And note that there are various questions/answers related to this, but it seems that this exact approach hasn't been investigated. (Maybe it's not possible like that.)
You can do this very easily. Simply pass ATTACH_PARENT_PROCESS to AttachConsole.
Whether or not the end result is sensible or practical is something I could not say. Both processes would read and write to the same console which could get pretty weird.