I'm currently working on automatic installation of GUI application using library UIAutomation PS Extensions (https://uiautomation.codeplex.com/). It works pretty well in cases, when I run it against existing Windows user session. I run my PS script, it opens a window and I can click on buttons and so on ..
However, problem raises when this library is called from remote machine. I call my script (which should open a GUI window and start controlling it) via PsExec from remote machine. This causes that script is not able to open GUI window on remote machine and starts to produce various exceptions.
As workaround for this, I can make PsExec to connect to specific existing session on remote host, but unfortunatelly this is not stable as I can't guarantee session's existence.
Does enyone know whether it's possible to force PowerShell to open new session (interactive GUI) through which I would be able to call UIAutomation commands?
Thank in advance
Matthew
I'm not clear on whether it's feasible to remotely open a new interactive desktop session in which to run GUI tests that require one. I'd be interested to find out if it's doable, since problems like this frequently come up when folks try to set up CI tests of Windows GUI apps.
Alternatively, I'd propose solving this by configuring the machine where your tests run to log in as a user at boot. Then you can remotely launch your tests as that user, and make use of their open session. That's worked in the past for me when I've run into similar issues.
Related
I am currently starting to work with SNNs on a GPU server. I am working with VS Code Remote-SSH package. Thereby, I'd like to use the tmux package to be able to start multiple processes which don't terminate when I disconnect the terminal from the server.
So far I used the https://cppdev.medium.com/vs-code-and-tmux-intergation-for-reliable-remote-development-e26594e6757a Tutorial. It already helps me that the process, I run doesn't shut down when I close the terminal but I didn't manage to start a second process on the server because each time, I open a new terminal, the already running process appears. What are your thoughts on that?
Thanks
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I'm developing on a VM and I'd like to automate booting and shutting down the VM whenever I launch VSCode into this project (over ssh).
I got around having to boot the VM by creating a script that launched the VM then VSCode. I use that to launch VSCode instead of the start menu whenever I want to work on this project. However, this solution doesn't work for shutting down the VM when I'm done.
Is there any way to accomplish this? Maybe some project setting that would execute a shutdown script on the VM when I disconnect, or some way I could hook up a script to run on my machine when VSCode closes that would shut down the VM?
Is there any way to avoid the janky startup script? Can I run a script when VSCode launches as well?
According to Visual Studio Code issue #10044 https://github.com/Microsoft/vscode/issues/10044, there is no way to run a script automatically from inside VSCode at startup unless you are willing to write an extension. Even if you are going to write an extension according to the API documentation https://code.visualstudio.com/api/references/activation-events for VSCode, There is no event for when shutdown occurs.
EDIT: Although it is not possible to do this within VScode alone, you could write a wrapper script when starting and exiting to to run the command.
I have this problem going on for few days, every time I open my laptop it starts Windows Powershell automatically.It's not causing me any problem as I close it once it opens, but I am quite annoyed by it and wants to know if this is some problem or just something went bad with my settings. I am using windows 10 pro.
There is probably an autorun entry for Powershell registered on your system. Without more information, it's not possible to tell how it got there.
Programs registering themselves to start up on boot is a common symptom of malware infection, but most malware would also try to hide any visual cues, i.e. the Powershell window would be hidden.
To troubleshoot further, you can try the free utility Autoruns available from Microsoft. Look for any entries related to Powershell.
I use Emacs remotely using X-Server in a Windows client and Linux server. I noticed that I can halt it using ctrl-z and then type fg 1 to get it working again. Is there some way that I could get it to halt on the machine that I am on, and then log into a different machine and start where I left off? When I start a new ssh session, the emacs job isn't associated to my terminal. There must be someway to "steal" it.
Also, maybe there's an Emacs feature that will do basically the same thing. However, I think closing and re-opening all my files and buffers would take quite a while.
Expanding on the idea of using emacsclient, you can look at what what someone did to solve the problem of editing a file from a different machine than where (s)he started running Emacs.
As of Emacs 23, you can run emacsclient in terminal windows using the -nw option.
Other solutions you might want to try are to use:
gnu screen
vnc
For years I used screen to "attach" and "detach" from a virtual terminal that sounds like your usage model. If you have the ability to use graphics... vnc is really great, just do your work in a vnc session and connect to it any machine.
And your last idea is already implemented by the package desktop (which is bundled with Emacs). Take a look at the wiki page for session management, which includes other alternatives to desktop, as well as add-ons for desktop to lazily load files.
You can run emacs as a server, and use emacsclient to connect to it. You can open multiple connections to the same emacs server, via ttys or X11.
When doing this, C-X C-C will close your connection, and leave the server running.
A simple way to do this by invoking emacs as follows. This will connect to the server if one is running, or create one.
emacsclient --alternate-editor="" -c
Sometimes I will be at work and have to run out the door leaving my Emacs session as it was. Later, I will open an Emacs instance to the same machine (usually using remote SSH) and find that I have files open in Emacs. Now the good news. Emacs allows you to "steal" those files using M-x recover-this-file. I recommend one of Trey's solutions if you can plan ahead. If not, you can use this recover file technique to keep progress moving.