this is all linux stuff. i hope i can explain it clearly, but its hard for me to think code in english.
xdotool is a command line program for sending x11 events. x11 is the gui system for linux and unix since the 80s. Im using xdotool because the vnc interface is insecure(1) and vmware doesnt have any other local method to control the virtualized mouse and keyboard.
the script broken down is in two parts, connected by a pipe. the first is
echo type `getclip.bash vault` |
echo is a print statement. type is the first word printed by it. ` replaces the output of the enclosed command on that command line. in this case, it takes the clipboard buffer of the vm named vault. so if foo was in that clipboard buffer, this line would translate to 'echo type foo |'
the | is called a pipe. it takes the output of the first part, and makes that the input of the command on the other side. so in this example, whatever is on the other side of the pipe gets 'type foo' as stdin. meaning its roughly equivalent of typing that in. standard in and standard out are topics you can look up.
next is "ssh $1" that just means run the next command on $1, which in bash, is the first argument to the script. following that is "DISPLAY=:0" which, on the target machine just sets which gui display to affect by the command. its preface to set an environment variable.
then is "xdotool -" the - means to read the command from standard in, which in the example, is 'type foo'. so all this just connects to the remote machine and runs "xdotool" then types "type foo" which sends those keyboard events to display 0 on the target.
this was the script i used for over 6 months without issue until the upgrade to sierra and fusion 8.5. usually, it would work the first few times. and ssh to that vm would also work. then when it stopped working, no other ssh from outside to the vm would work, usually until rebooting the vm. sometimes, after some time passed it would work again.
anyway, its not xdotool that im worried about. its whatever is causing that problem since it cuts off ssh access. something else that confuses the virtualized network stack could also trigger it.
my macbook is out for repair. when i get it back, ill make a vagrant file for you. thats probably the easiest way to make reliable error condition.
whats get_desktop?
(1)the vnc server uses a network socket, which by default is open to the lan (and possibly the world), and you only get an 8 char password protecting it. this is easy to brute force. there is an undocumented option for restricting it to listen on a specific address, but processes from another user can still get to it. my suggestion is to make this a unix domain socket with permissions for only that user. if you combine that with a password timeout and use it from the terminal with keyboard security turned on, then any other process would need a privilege escalation to get to your vm. this is discussed in another thread.
if its possible, from a script, to change vnc options, then we have another workable solution. when typing is needed, just enable the socket with a randomly generated password, type in, disable. next time, re-enable with another random password. my mac is being repaired, so i cant try this till i get it back.
p.s. vmware really should document scripting interfaces and config files! look at virtualbox for a good example of how to do this.
What does 'xdotool -' do? There would not be output for 'xdotool -' even without ssh. Could you try other options? say 'get_desktop'