I am working on an embedded system (consider a layer 2 switch running linux). I am connected to it using putty ssh.
When I press CtrlL, it doesn't clear the screen. While the same thing works on Ubuntu machine.
I want to understand why the key combination is working on normal linux machine, not on switch.
The CtrlL combination is handled by the terminal, not the shell. Unless you configure PuTTY to acknowledge it (assuming you even can in the first place), it will have no effect.
Related
I have used an script in past that enabled me to connect me to multiple unix machines, much like using a tab. Its just that I forgot the name of the script. Anyone know about it?
I suspect you're referring to GNU screen, which is a terminal multiplexer that allows you to have multiple virtual terminal windows in a single normal terminal window (ala PuTTY). I'd suggest tmux as a better alternative, but they're essentially the same. There are other solutions that will allow you to do tabs in the terminal client, but that depends on your OS (I'm assuming you're on Windows), and you'd have to initiate each connection individually. screen/tmux is the way to go most of the time.
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
At present we are developing a graphic app on a linux box using opengl. We have had a bit of trouble getting a decent debugger working. At present we use GDB via a ssh connection, but that is a tad painful. Next we have tried running DDD on the target platform, but we run out of space on screen. Next we have tried running an xserver via cygwin on windows and doing an "export DISPLAY=RemoteHost:0.0" on the linux box. In this situation DDD will run on the windows box, but when we boot the app it also wants to pipe its output to the windows box.
What we really want to do is have DDD output on our windows box, and the output of the main app on the linux box.
I am not a x11 guru and I would love some help in this area.
Cheers
James
While logged in into the linux box:
DISPLAY=windows-box:0 ddd /path/to/app
DDD should now pop up on your windows box. If you run the app at that point, it will attempt to display on windows box as well, since the DISPLAY environment variable is inherited. You need to reset it:
(gdb) set env DISPLAY :0
(gdb) run
At that point, the app should display on the linux box, as desired.
Many applications accept -display command line argument. If yours does, an alternative is to do this:
(gdb) run -display :0
instead of resetting the DISPLAY environment variable.
I have an HTPC (with an HDTV as the monitor) running Ubuntu Karmic, and various other computers in the house. Sometimes I want to run X11 applications (usually, but not always, XBMC) on the HTPC displayed on the HDTV, but I don't want to have to physically go to the HTPC to do so; I want to do so from another computer in the house.
If I use ssh then, of course, the applications don't run because X isn't started on the connection. I don't want to use ssh -X or ssh -Y because I don't want to forward the display to my laptop: I want to do things in the X session already running on the HDTV. I don't want to use VNC or its ilk because sharing a 1080p display over an 802.11g network is nobody's idea of fun.
What I want is a command to run in a remote bash shell that executes in the local X session. Any ideas?
Try looking into the "xhost" command
Seems like I recall, 20 years ago, "xhost +" or something like that would cause your local X server to accept all incoming requests to create windows on the screen or grab input devices.
This is probably still reasonable to do only if you are behind a home firewall.
On the machine that actually runs the program whose display you wish to forward, you specify a -display option or DISPLAY env variable to forward the graphics window.
X security has changed in the past 20 years, I'm sure... so this may or may not work for you -- but I notice the xhost command is in my ubuntu 9.10
At work, I use Cygwin a lot because it offers me a small oasis in the vast desert of Windows. I inevitably end up running some non-Cygwin programs through the bash shell, such as build scripts (batch files created in-house) and the Subversion CLI binaries (I have the Windows ones installed). 99% of the time, I don't have any problems using this setup. The other 1%, however, causes a strange issue:
With both the build scripts and SVN, most of the time the enter key is interpreted correctly. For instance, I'll kick off the database creation script and it will prompt me for the server name. I type in "localhost" and hit enter. Everything's fine. Then it gets to the end, if there are errors, and prints things out using more. No key that I press is recognized by more. I have to Ctrl-C out of it.
Similarly, if I do a Subversion update, normally everything is fine. In the case where the interactive conflict resolution happens, however, I'll usually type in "tf" for "theirs-full" and hit enter, but nothing happens. I have to Ctrl-C out of it and re-run the update with force merge or use TortoiseSVN in Windows to do it.
Any idea why Cygwin seems to randomly not be passing the enter key through to the programs? I considered that it may have something to do with Unix vs Windows style line endings, so I've tried typing those characters manually, but that doesn't seem to make a difference. Thanks.
Edit: I just had this happen to me again and I realized something. It was SVN prompting me for a password. I typed in the password, which it echoed to the screen (bad) and hit enter... nothing. Hit enter a few more times, the cursor moves, but nothing happens. I hit Ctrl-C and it dumps me back to bash, which then says "bash: [my password]: command not found" followed by a number of new prompts equal to the number of times I hit the enter key. So what happened is the input never made it to SVN, but somehow got read by bash after SVN exited. I thought that may help someone figure out what is going on.
Unfortunately, I think you are hitting one of the issues of Cygwin and windows/dos console apps. See "Console Programs" at http://www.cygwin.com/cygwin-ug-net/using-effectively.html.
It is just a limitation on windows console apps. This behavior is common for the windows myqsl cmd client and svn client, for example.
Here are some things to note -- I've successfully used this approach with both the Windows mysql as well as Windows svn clients:
1) Try making sure you do NOT have "tty" in your CYGWIN environment variable and see if that helps (unset it in My Computer->properties->advanced->Environment Variables and close/restart any cygwin bash prompts).
2) Do not use RXVT -- instead, use the basic Cygwin cmd prompt. This is because RXVT implies "tty" and will break #1 above.
3) Try finding a "native" Cygwin package for the cmds you are having issues with instead of using the Windows cmds. (I haven't found a 1.6 svn client for cygwin yet, though.)
Good luck!
Dustin
The lengthy discussion on the mintty project is here - http://code.google.com/p/mintty/issues/detail?id=56
One solution mentioned which worked in my case (entering authentication passwords for native subversion) is conin - http://code.google.com/p/mintty/downloads/detail?name=conin-0.0.2.zip&can=1&q=label%3ADevelopment
$ conin svn list https://{repo}
Password for 'user': ******