I'm looking for some guidance on an approach to automate the process of quickly switching between projects.
Putty Windows (2 of them):
Vim with project.session open (multiple tabs)
IPython open to the working directory of the project
What I want to automate in its respective windows:
Save all files, save session, close vim, change working directory of vim to next project, open related project session.
Close ipython (as I often restart it during development and want a fresh instance), change directory to next project'ss location, open a new ipython
A magic solution would be a single command that would change the state of both putty windows. However, since I have no idea how that would be done my current approach would be:
Attempt to figure out how to bind all that Vim stuff to a key press or a custom vim script that is used like: :SwitchProj "projectName"
Write a bash script or find a bash command that will allow me to type as little as possible to perform the directory switch and open new ipython interpreter.
As I have very little experience on Linux and SSH I would be interested to know how other's have solved this problem or would approach it!
I believe that the Linux screen command should satisfy you. Google gives you many tutorials, like this one.
I sadly confess that I am not very familiar with screen. Learning it is in my todo list
If you use the Gnu Emacs editor, you can also open many shell buffers inside (and other interactive buffers, like gdb sessions, compilations, grep search) and edit many files. I do that very often. You can use emacs thru a tty interface, such as provided by ssh.
You could also use ssh with e.g. -X to also redirect X11 windowing. For you, that means that you'll need to run an X11 server on your local Windows machine.
Related
I was wondering, is there a way I can edit files inside a live linux server using a text editor? I am able to edit using the nano command but that is not very friendly. Can I achieve the same using an editor.
vi is an editor. If you mean graphical editor, then it depends. At first glimpse, you have two options: A) Open the file using some file share (nfs, samba, ftp?) on your client computer using your favourite editor, or B) Use some ssh client which is capable of "tunneling" an X connection (putty?) and use an editor running on the server machine, displaying GUI on your client (which acts as an X host).
You can install a better editor, like vim or emacs on your Linux server.
You could also install X-client editors like gedit (and many others) and use ssh -X to access your server. You need some X11 server in front of you (on your laptop).
I'm using julia and gadfly to draw some plots on a remote server (connected through Putty) and the plots are supposed to open in my default server. They open in lynx, and so don't look like anything really. I'm presuming lynx is the default browser on my work server, and I was wondering whether there is any way to open them in chrome or firefox? I'm not the server administrator and have no permission to use all commands (ie sudo etc).
When trying to use xdg-utils I get an error saying "command not found" and I don't have any applications in my /usr/.local/applications nor could I find a mimeapps.list in the directory.
Is there anything I can do to open these plots in another internet browser instead of lynx? Thank you!
The order of preferences
Gadfly plots on Julia's display if it can (for example if you're using an interactive graphical notebook with Jupyter).
If there's no suitable way to render on the REPLDisplay, Gadfly will save the plot into a file, then trigger some platform-specific "open this file" logic.
Julia's own display
This is almost certainly the best option. If you run your Julia code in an environment that knows how to display your plots (such as an interactive graphical notebook with Jupyter), then there's nothing more to do.
If you must run your Julia code from a text prompt, you can use a text-based backend renderer, or deal with the fallback process.
xdg-open
Gadfly's fallback display code uses xdg-open to display plot files on Linux-based systems.
The xdg-open tool is part of a package called xdg-utils. The xdg-utils package contains several commands, but xdg-utils is not itself a command -- that's why trying to run "xdg-utils" fails with "command not found".
xdg-open has its own chain of opening things: it will try the opening procedures specific to GNOME, KDE, or whatever desktop environment you're using. It falls back to something called "perl-shared-mimeinfo".
Another tool in the xdg-utils package is xdg-mime, which can query the current file associations as well as change them. You need administrator privileges to change system-wide associations, but you don't need any special permissions to add your own per-user associations.
Since Gadfly is writing to a file then asking xdg-open to open the file, you'll need to handle the filetype (rather than "browser" or URL handler). It might look something like this for HTML files:
$ xdg-mime default mybrowser.desktop text/html
Which computer runs the browser?
Now, you mention that you're using SSH and PuTTY to connect to this server. PuTTY provides a text-based interface to your server -- even if the server had a graphical browser like Firefox installed on it, PuTTY couldn't display it. (You'd need something else on your computer that the server could use to draw the browser window.)
It would probably be more comfortable to use your computer's own browser.
So what do I do?
Launching a browser is a bit weird for a server computer anyway, and it can be fiddly to make it happen. So my recommendation would be either:
Skip PuTTY, display directly in a Jupyter notebook.
Save your output as HTML (or SVGJS) somewhere that your computer's browser can access it.
I have found lots of questions about coping content of a file in Vim from one file to another and of course there are various ways to do it (1-2). I'm working on a remote machine and I'm going to copy large amount of data from a file in Vim to my laptop. None of the methods I have found yet works for coping from a remote machine. I have to use scp for any thing that I need from the remote machine. Do you have any idea?
I can't use "*100yy to copy content and remote machine does not have
any graphical editor. – Abolfazl
Naturally, if the editor has no notion of a GUI or a window system, it cannot use the clipboard, let alone that of your networked laptop. One option is to use the copy function of the local terminal program where you enter ssh, but of course that is practically limited by the terminal size.
If your laptop runs Windows, I recommend using WinSCP instead of ssh and the remote vim - you can configure WinSCP to edit the remote file with your local gvim, with all its features.
In your terminal:
$ man ssh
/-X
We are using groovy to build our java applications. The goal of the groovy script is to checkout from SVN, run MVN, download release notes from Jira, allow user to edit release notes, then upload everything to S3 for public consumption.
My question comes in on the editing of the release notes. I would like to have groovy run vim on a txt file and allow the user to edit the file and quit vim. On vim exit I would like the script to continue along. This should run on a headless linux server. I have it working locally on my mac using the open command but we are moving our builds to a central AWS linux server.
Something like this is what I'm looking for:
println "Downloading release notes..."
"vi RELEASE-NOTES.txt".execute().waitFor()
println "Uploading the edited release notes here"
FWIW the solution I am using on Mac OS is:
"open -eW RELEASE-NOTES.txt".execute().waitFor();
It opens TextEdit, allows me to edit and save the file, on quitting TextEdit the app moves on and uploads my edited file.
I think the VI solution fails because you no longer have a console (but you weren't very specific about this).
I'm embarassed to say I don't know how to fix this on a Unix machine, on DOS I would use "command /c vi" to run it in a new command shell, but even then it might be a trick to give that shell a "Console" for you to input in (in windows it would open up a new window).
Something like what you said MIGHT work if you piped the user input/output to the app stdin/out, but I bet some linux guru knows a better way.
Problem is that "Groovy" owns the console allocated to user I/O. If you could put groovy in the background (equivilent of ctrl-z) or switch to another console (perhaps using Screen or Linux's multiple consoles) you might be able to pull it off, but I probably wouldn't try it myself.
Redirecting I/O might be a better bet, or just go find a non-gui text editor written in Java and integrate it (Might be your best bet).
It doesn't seem possible, as per this answer, because java's way of handling processes is just piping streams of bytes, which doesn't relate to piping video/tty/whatever. A possible solution is to open a new window with xterm. Since you are on a headless linux, i'm not sure this will work. Are you connecting via SSH? What about trying connect to the server using ssh -X and then run the command? (Or does the "headless" implies the minus X doesn't work? :-) )
println "Downloading release notes..."
['xterm', '-e', 'vi RELEASE_NOTES.txt'].execute().waitFor()
println "Uploading the edited release notes here"
And... have you thought about writing such a script in shell? Seems a bit more suited, IMO.
I think #Bill K's suggestion would be great, but after a quick googling i couldn't found any java CLI editor.
On a machine I don't have physically access to, I left gedit open with a text file I forgot to save. I can ssh to that machine. The OS running there is Ubuntu.
Is there any way I can save that file remotely?
Look at xdotool, which can programatically activate/move/resize windows, and simulate keyboard input and mouse activity.
xdotool search --classname gedit key ctrl+s
This will search for all of gedit's windows and press ctrl+s in them.
Yup! I can think of two straightforward ways.
If you have SSH access and root privileges, you can tunnel in and install and configure a remote desktop viewer (or use the default VNC, vinagre). You can then connect to your desktop, find the gedit window and literally press "save."
You can use X forwarding over SSH to forward the gedit window to your local machine, where you can also just press "save." Note that you'll have to change the X display of the gedit instance so it's forwarded. This may be slightly tricky, but you can give it a try. You'll find many guides to X forwarding with a simple search.
There's definitely a hackish way to take the contents gedit is holding in memory and write them to file, but I think using a VNC client is a much, much simpler option.