Home"The files are inside the computer.." is one of my favorite quotes from the movie Zoolander. However, it's not that easy...there is a probelm. I keep finding myself in the middle of some serious development effort and am coordinating between two or more different editor programs. Usually it's vi and Eclipse. Sometimes Mousepad comes along for the ride. It works alright but causes me extra work, having to keep in mind the key bindings and commands for all these various editors. Recently I stepped back and said: 'why am I doing this?' Why not just use one editor and be done with it? Well, of course Eclipse being my favorite editor the next question was: 'why am I using vi and mousepad all the time?'. The answer was simple: they are easy to envoke from a shell. I am an average Linux user and use the shell for many things. A shell session is like a conversation you have with your machine. Leaving the shell and going into Eclipse (or any other program) is a mental jump and often it's easier just to run something local to that shell. So, what I wanted was something that would let me edit a file from the shell as easily as I can with vi our mousepad. Enter steb.
As usual when I think I have some kind of Great Idea, I do some googling and find it's been done before, usually many times. This is a good thing and in most cases I happily go on my way consuming the great efforts of some previous masterpiece. In this case the mythic Ed Burnette had produced something similiar with Windows UI integration. This work seems to have been lost to the sands of time. After that came Sunshade from Matt Conway. The code was really more for Windows DnD integration, less for the shell. But, most of the code I needed was already there, and I also only needed Shell integration, nothing else. So, with Ed and Matt's code in mind I wrote steb. From the command line, simply type:
$ steb myfile.txt
And boom, all of a sudden your already-running Eclipse instance pops up loaded with the file! Why the name 'steb' you ask? Well it sounds friendly doesn't it? I can see myself saying, 'Hey steb while you're up can you get me a cold one from the fridge?'. Also, it happens to correspond to Shell to Eclipse Bridge, which I think is nice. Essentially I have a plugin that listens for file paths on a port. I then have a client program that, complements of netcat, pipes a filename to that port. Poof, Eclipse and Terminal are talking like old friends. Also, if you're a gnome-do user, steb integrates just as nicely there, as long as the client program is on your path.
If you're interested in tighter integration between Eclipse and your shell conversations check out steb's updatesite at http://bugcommunity.com/downloads/files/steb/updatesite. BSD-licensed source is available at svn://svn.buglabs.net/ote/branches/steb. After installing steb, you'll want to install the clien program somewhere on your path. My client program is available at http://bugcommunity.com/downloads/files/steb/steb. You could make something else, maybe that loads Eclipse if it's not running. I've only tested on Gentoo Linux, but it should work with any Linux. Mac and Windows support would probably require some other client program, but the plugin should be generic.
Loading recent content...
Post Comments
Add Your Comment!
P.S. I like my Python version because it
Python version of steb executable.
(In an amazing coincidence, I came back to this page to send along my python version of the steb executable, only to find that someone else had posted a ruby version just today! I'm including it inline because it is very simple.)
#!/bin/env python
import sys, os.path, socket
if len(sys.argv) < 2:
sys.stderr.write("usage: %s <file> [<file2> ... <filen>]\n" % sys.argv[0])
sys.exit(1)
for path in sys.argv[1:]:
full_path = os.path.abspath(path)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('localhost', 4404))
s.send(full_path)
s.close()
shadowbq, glad you find steb useful! Ruby client looks cool...but maybe file-not-exist check isn't needed? Eclipse will create new files for you if they don't already exist...
Ruby version of steb executable
http://gist.github.com/325430
Works great on windows with winscp and aptana studio(eclipse) to have "live" ssh editing!
Thanks so much!
PrzemekM, that is a great idea! I am working on that and being able to use named pipe instead of socket now and hope to have another release out shortly.
Wow, a truly excellent idea!
Though if we go this far, it would be nice if the solution also allowed to move to a specific line in the opened file, for instance like it is possible with vim or gedit when you can launch the program giving the file name and "+line_number" on the command line :-)
I've just released 0.2.3 which fixes an annoying bug. If you have a closed project in your workspace that contains a given file you're trying to edit from the shell, previous versions would fail with an error. This has been addressed. Still looking into more secure approaches like named pipes.
Nice post,
Keep up the good work,
Anyway, thanks for the post
Ken,
I just glanced at the wikipedia on named pipes ( http://en.wikipedia.org/wiki/Named_pipe ). It mentions support for windows. I'm just not sure how that would hook into java :/ Sorry for trying to make your simple helper utility into a convoluted nightmare!
Hi Ron,
I see what you mean. How about a named pipe? I'm not sure that will allow non-Linux users but I could enable it as an option at the least. Are you aware of a better cross platform IPC approach?
thx
ken
Ken,
This plugin is attempting to solve a very real limitation with eclipse, and it does so in an innovative way. By problem is using a blatantly opened port. I was able to connect via telnet and send garbage characters through (control characters specifically). An outside machine was able to connect to the port briefly before being disconnected (the space between socket.accept() and the isLoopbackAddress check). Is there a different IPC mechanism that you could piggyback on? It just seems a little risky to have that port dangling there...
Ron
I revised the client program. It has some issues with some relative paths. I used the technique identified on this page:
http://www.robertpeaslee.com/index.php/converting-a-relative-path-to-an-absolute-path-in-bash/
Here is my new client:
#!/bin/bash
# Client script for Linux Shell Eclipse Bridge (steb)
# Copyright (C) 2009 Ken Gilmer
tpath=`dirname $1`
echo "`cd $tpath; pwd`/`basename "$1"`" | nc localhost 4404
James,
I'm back in the office and got a chance to play around with steb on a mac. You're right, it doesn't work. After some digging I found that the problem was with the JRE version, not the plugin itself. I was building for Java6, which I guess is still not used. At least not on the mac I tried. So, I produced a build built with Java5 and was able to run it succesfully on the mac. I've updated the original updatesite URL with the new version (2.2). Please have a go and let me know if it's working for you.
thx
ken
A preference page? I'm not seeing one. I've also tried it in 3.3 and 3.4 now (I had old copies sitting around). I don't see a prefs page for steb (or Shell to Eclipse) in any of them. I can disable the entire feature, of course (and have toggled that with no effect), and I can see feature properties, but I don't see a prefs pane with a socket listener toggle. I also don't see any errors in the error log. Sounds like it just isn't starting up/installing prefs pane, for whatever reason. I've got a Linux machine at work, I'll give it a try there tomorrow. I do most of my work on a Mac so that's where I really want it to function, though.
Hi James!
Hmmm, I haven't tested Steb yet with Eclipse 3.5 but I don't see any reason why it wouldn't work. Once installed you should have a steb preference page that will toggle the socket listener. Can you toggle that a few times and see if any errors are generated in the Eclipse error log? You can access the error log view from Window -> Views menu entry.
Mac support should work with the client you give since both bash and netcat (nc) are default installed and OS X is basically BSD Unix. It should, but it isn't working for me. When I run steb with the plugin installed and Eclipse open, nothing happens. Manually running nc doesn't work either. I did a portscan on localhost and don't find an open 4404 port, so that makes me think the problem is on the plugin side (It *should* be showing an open 4404 port, right?). My firewall is off, so I'm not blocking the port. I'm running Eclipse 3.5. Sadness. I REALLY want this tool. I've wanted it for a long time. I suppose I can recompile steb from sources and add some instrumentation to try to see what is happening. Do you have any thoughts on why it might not be showing an open port from Eclipse?
Thanks Ed! Maybe "legendary" is better...?
"Mythic"? LOL
Here's the code for FileOpen from 2003:
http://sourceforge.net/project/showfiles.php?group_id=73634
It was also adapted for EasyEclipse:
http://fisheye1.atlassian.com/browse/easyeclipse/easyopen/org.nexb.easyeclipse.open.file.client/src/org/eclipsepowered/fileopen/EclipseClient.java?r=1.1
Feel free to use any part in your project.
Cheers,
--Ed
Thanks Dave! I'll fix the feature category next time I make a build.
Genius! I can tell I'll be using steb a lot throughout the day...
I notice the plugin is named "Shell to Linux Bridge" on the update site -- you may want to rename that :)
» Comments RSS