I have a project to do in school which is baffeling me... I am SSHing into a Solaris computer in the computer lab from my own Debian box via
ssh -Y name#***.cs.<school>
I can get in just fine, and the X11 seems to be working also. However, this peticular project requires us to find the window id of a netscape window via xwininfo and use this information in the following command
netscape -id 0xa00029 -remote 'openFile(/path/to/html/file)'
Now, if this netscape is the only window I have open (other than xterm), the preceding command works just fine. However, if I have any other iceweasel windows open (regardless of the order in which I opened netscape/iceweasel) the command will forward to my iceweasel despite the facts that I'm running the command in my SSH session and the two windows have very different window ids.
All of this eventually has to go into a C program, but I can't even get it to work reliably manually!
Any ideas?
P.S. I just saw this that may help. When I SSHed via Cygwin/X using the same command, I get this error
Warning: No xauth data; using fake authentication data for X11 forwarding.
Not sure if this is important as I can still use X11 (aparently) perfectly.
Thanks.
P.P.S the -id switch is documented in the netscape man pages:
-id window-id
Identifies an X window to receive -remote commands. If
you do not specify a window, the first window found is
used.
When you use ssh -Y, you're requesting that remote clients be forwarded to your local X server, with full permissions. The Netscape/Mozilla/Firefox/Iceweasel/Etc. remote protocol runs through the X server, so it'll be forwarded too.
http://www.mozilla.org/unix/remote.html documents the protocol, and mentions nothing about -id. Nor does a very quick look at the source (e.g., http://mxr.mozilla.org/seamonkey/source/widget/src/xremoteclient/XRemoteClient.cpp#202) look promising for there being an -id option.
I sat down to an actual machine to perform the same tests, and they all fail there too... I would open 2 netscape windows and try to direct the command to one at a time. The most recently opened one would work properly, but any command directed to the other one would be forwarded to the same window, so at this point I am convinced that the problem lies in the command being not properly implemented and/or everything on that system being really, really old.
if I have any other iceweasel windows
open (regardless of the order in which
I opened netscape/iceweasel) the
command will forward to my iceweasel
despite the facts that I'm running the
command in my SSH session and the two
windows have very different window ids
Iceweasel is coded that way. It tries to have only a single process run for all open windows for that user.
Use the -no-remote command line option to avoid it. See http://kb.mozillazine.org/Command_line_arguments
Related
I am using pyautogui in Windows 10 with Python 3, in a virtual machine accessed by remote desktop.
Unfortunately, the program stops execution when I close remote connection, giving "OSError: screen grab failed".
I've searched for a solution online, but the only workaround that I've found is from this link
Use a remote desktop client that allows you to keep outputting the display, even if you minimise the window/close your PC. I used terminals (https://terminals.codeplex.com/ - not affiliated with them at all just recommending as it solved this issue for me).You can set this up to persist the display, and your code should then run fine.
The problem is that I can't find a setting for persisting display. I've also found this:
pyautogui._pyautogui_x11._display = Xlib.display.Display(
os.environ['DISPLAY']
)
... but it doesn't seems to work either (gives me errors...).
Do you have some workaround to do the trick?
Based on an answer from here:
when you disconnect from RDP, Windows lock the computer and does not render the screen any more so any automation apps which needs GUI fails to work.
To disconnect from RDP without losing the screen you can disconnect using following commands as administrator (its better to make a bat file and run that file as administrator when you need to disconnect from RDP):
for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (
%windir%\System32\tscon.exe %%s /dest:console )
I have resolved using TightVNC instead of remote desktop and detaching mouse cursor.
I am currently using X11RDP to connect to a RHEL 6.5 endpoint, as root user. All X apps work fine, and directed properly to the right display (say 11.0).
Now if I switch to another user (su - user1), then I try to open any X app (say xterm) it will be unable to open the display (even though it is also 11.0).
I do not believe the problem to be with xauth (magic cookies, etc), or the DISPLAY environment variable not being set correctly, or allowing connection with xhost +; but rather something with XRDP.
Any help would be appreciated.
The solution to my problem was actually in how x11rdp was starting.
It starts the x server with -nolisten tcp.
If that part is commented out in /etc/xrdp/sesman.ini for x11rdp then the problems described above will be gone.
Hope this helps other people experiencing the same problems.
I am working my way through 'The linux command line' (http://linuxcommand.org/tlcl.php) . Since I don't have a local linux environment and I have to work in windows , I am telnetting into an Ubuntu 14.4 LTS instance on EC2 , with putty. On page 114 , when I run the xlogo command I get:
ubuntu#ip-172-31-22-65:~$ xlogo
Error: Can't open display:
How can I get this working?
xlogo will try to access the current Xserver to display a logo. If you're telneting to a box, you will not have an X server available, which is what that "can't open display" message is saying. It's trying to look at your DISPLAY environment variable to use that to show the logo on, but you don't have a display to use, and thus have nothing in your DISPLAY variable.
You will need access to an X server somewhere to do that step. One option would be to install cygwin on your Windows machine. Then you wouldn't need the remote linux box for most steps I imagine, because you could just use your local cygwin environment. Even if you want to use the remote box still, if you use cygwin and launch an xterm with it, you could ssh -X <host> and that will export your DISPLAY to that remote machine so it can display back on your windows machine.
As I mentioned in the comment under Eric Renouf answer, I am working thru the same book. That part of the book have some testing of creating users, groups, shifting users, group permissions etc. I found that I needed to log the same user out quite some times. The last time logging that user out, I got a message saying xlogo is terminatet, like it was hanging on that user?
After everyone was logged out, I logged in as sudo and everything worked again.
I have inherited an application that is launched at login time from my server's .bashrc. The application starts two gnome-terminals. If I am logged in with a gnome desktop, it works great. Two terminals open on the desktop.
Sometimes I kill the application and must restart it. Works great if I launch it by hand from a terminal on the desktop (causing me to have 3 terminals open).
However, if I telnet into the machine where the application is installed, as .bashrc executes I get all sorts of "cannot open display" errors.
Well, of course I can't, I'm not logged in from a gui interface, But a desktop IS running on my server and is logged in using the same ID! Why not put the terminals there?
So how do I say, in bash, "start this application and send its output to 1) the display where you are now, or, 2) the one currently up on the server?" (I assume that found by looking at the env var display?)
Ubuntu 10.04 64 bits. I telnet to the server to start the vncserver so I can access the aforementioned desktop.
Thanks,
It depends on the application exactly, but generally you simply export the DISPLAY environment variable and the application should start on the specified display.
eg:
export DISPLAY=localhost:0.1
xterm &
Some applications would also (or alternatively) take a --display command line argument - check into the specific options available for the applications you're using.
I'm trying to run screen (version 4.0) in the latest version of Cygwin under 64-bit Windows Ultimate, and it doesn't want to work. I launch a new screen session using "screen -d -m -S screen1". When I connect to it using something like "screen -A -d -r screen1" the process hangs. When I list screens with "screen -list" it reports the screen as "possibly Dead".
Any idea how to get screen working in my environment?
I just ran the same commands you did, and had similar problems. But I use screen under 64-bit Windows 7 all the time.
I just use screen to start a screen session, and screen -dr to reattach to the same session later. (I've actually been using screen -U and screen -drU, but I just realized that with defutf8 on in my $HOME/.screenrc, the -U isn't necessary.)
I haven't figured out why your approach doesn't work.
I am also currently trying to get screen work on a cygwin installation on a windows server 2008 installation.
it works in principle, so I can reuse sessions, but its quite buggy:
1.) only sessions started through an rdp session (on the windows desktop) are able to access mounted network shares, sessions started through ssh can only access "c". (okey not really a screen bug, more cygwin in general)
2.) detach doesn't work through ssh. strg+a+d just freezes the terminal, by using these keys in that sequence: [strg+z, bg, %, strg+c] I can get back into the screen session I've last visited.
3.) this leads to the funny state that I can have the same screen session attached multiple times, and see the input and output on all instances