[RFE] create a shell interface mode for wnbd-client #120
Description
Description:
It is desirable to have a shell interface mode for wnbd-client, just as qemu, guestfish, do.
It is desirable that the no-arg invocation starts the shell. Presently the no-arg invocation just prints the help.
Example output:
PS> D:\vstorage\nbd\wnbd_client\wnbd-client.exe <enter>
WNBD> help<enter>
<show help>
WNBD> version<enter>
<show version>
WNBD> uninstall-driver<enter>
<uninstall the driver>
WNBD> exit<enter>
<say goodbye, and return to shell>
PS>
The shell mode is just a simple read eval-string-array print loop that
- Treats the input-string-array as if it were command line arguments, and uses the same parser/invoker
- It must ensure both that output and errors returned by the parser/invoker make it to stdout/stderr and are readable by user.
- Maybe print the return-value if it encodes various error conditions (0=success)
- It must ignore whitespace entries (empty lines).
- The command/keyword
exitis the only one that is newly introduced, which terminates the loop, exits the wnbd-shell process and returns to outside-shell.
Reason:
The advantage of a shell interface mode is the executable is already loaded in memory, running as a process, waiting for user's stdin input.
This is unlike starting the application with arguments on the command prompt, wherein the binary has to be loaded from a drive, and a new process has to be created.
When drive lockup happens, OS might not be able to load and run a new command, an it prevents doing the following save from trouble strategy, which is to have a open terminal window with the wnbd shell running.
nb: IMHO #63 still happens, presently it is closed as it is hard to identify where the fault is. qemu on windows is a bit buggy, but I argue that even if nbd-server is buggy, wnbd should detect lockup situation, perhaps eject disk and bailout.
The following is an excerpt from #63-comment-997204171. Uninstalling and reinstalling the driver is the only way to unstuck the situation. At this point, all not-responding processes/apps come back alive. Until I discovered this, I was only force shutting down laptop. the following don't work ctrl-C or taskmgr-end-task on qemu-nbd or xcopy, attempt wnd-client unmap.
I think this was possible because the windows-OS was not so stuck that wnbd-client could not run. The drive lockups can be so bad that even thats not possible. When stuck happens, its possible to switch between open windows, that take user input. But the moment an application has to access the disk (such as how a browser always does, or when pressing ctrl-S in notepad) the gui becomes becomes stuck. Windows-taskbar becomes stuck quickly for the same reason. Its possible to start taskmgr via ctrl-alt-delete but, taskmgr can't really load any information in its gui.
Its really important, that when in shell mode, wnbd-client does not access any disk file/cause disk-access, not even configuration files etc. Otherwise it will also get stuck. This is unless the command it self require a file argument like install-driver. For this reason I don't recommend implementing history as history would require maintaining a history log on disk. Or maybe an option to skip reading and writing disk-state.
There's no guarantee that shell mode will be able save the lockup situation. But its worth a try, and even if it doesn't its a feature addition that is harmless, small, simple and low maintenance.