Not sure what I may have done wrong (followed this: http://danieldemmel.me/blog/2012/09/02/setting-up-rmate-with-sublime-text-for-remote-file-editing-over-ssh/), using a custom 2224 port.

Opening remote files works perfectly but ctrl-s in sublime text 2 does not impact the remote file. Any idea what might be going on?

Thanks for this BTW, it is awesome! Definitely appreciate not having to rely on ruby to not be screwed up :)

Here is the problem I am seeing:

w/ standard locale textmate edit I can:

1. edit file in textmate, save
2. edit file outside of textmate, save
3. textmate updates itself to have the version from step 2

rmate textmate is not behaving like that for me:

1. edit file in textmate, save
2. edit file outside of textmate (on server), save
3. textmate stays at the version from step 1

There does not seem to be a feature to manually refresh textmate w/ the current version either, so its a really sticky situation.

@dhowden Waauw I really like this project, especially rmate.sh because it runs almost everywhere.
I viewed the code and realized for the first time how to use tcp in bash.
Do you think it is possible to not only edit a file but also browse the folder over the tunneled ssh port in sublimetext?

I recently had to set up my remote server again. The newly-downloaded rmate stopped working. I get the following error:

[user@log-1 ~]$ rmate example.txt
~/bin/rmate: line 81: syntax error near unexpected token `$home/."${0##*/}.rc"'
~/bin/rmate: line 81: `$home/."${0##*/}.rc"; do'

If I use v1.0.1 from Jan 8, 2018, I do not get this error and my Sublime Text successfully opens example.txt.

I am not an experienced user in shell scripting. I can provide more information if necessary.

as cd dirname $1`` echoes the target dir on bash for me

rmate does not support the +N syntax which is supposed to place caret on line number after loading file, just like --line:

$ ./rmate +3 /etc/fstab
There is more than one file specified. Opening only +3 and ignoring other.

Others editors like vi, emacs, mg support this, even nano:

emacs +3 /etc/fstab
vi +3 /etc/fstab
nano +3 /etc/fstab
mg +3 /etc/fstab

I prevents some program like 'debchange' to work:

$ export EDITOR='rmate -w'
$ debchange -i
There is more than one file specified. Opening only +3 and ignoring other.

and SublimeText opens the file called "+3"

Would it be possible to support +N as an alias to --line=N?

Thank you

PS: sorry about my initial bug report, I apparently triggered a shortcut to open the ticket before it was done

head -c$value <&3 >>"$tmp" 2>/dev/null

ended up overwriting remote file with the following:

user@host:~$ more /etc/apache2/2.2/httpd.conf
usage: head [-n #] [-#] [filename...]

I am having an odd issue wherein suddenly port forwarding stopped working in a particular scenario for me. By default I have ssh set to use the following config (my ~/.ssh/config file):

Host *
    ControlMaster auto
    ControlPath /tmp/%r@%h:%p
    ServerAliveInterval 120
    ServerAliveCountMax 3

    ForwardX11 yes
    ForwardX11Trusted yes

    RemoteForward 52698 127.0.0.1:52698

I then initiate ssh to the server (ssh [email protected]) and query my local workstation to make sure that there are listeners for port 52698; sudo lsof -i -P | grep 52698:

AppName   40262        username   45u  IPv6 0x4b497d2de68055a1      0t0    TCP *:52698 (LISTEN)
sshd      92207        username   14u  IPv6 0x4b497d2d9e7ec4a1      0t0    TCP localhost:52698 (LISTEN)
sshd      92207        username   15u  IPv4 0x4b497d2dbb985641      0t0    TCP localhost:52698 (LISTEN)

I then likewise make sure that the port is active on the server, lsof -P | grep 52698:

sshd      16366      root    7u     IPv6             196798        0t0        TCP localhost:52698 (LISTEN)
sshd      16366      root    8u     IPv4             196799        0t0        TCP localhost:52698 (LISTEN)

I simply get hangs or effective timeouts right now when I initiate rmate.sh on the server to which I'm logged into in each case. With the rb version of rmate I'm getting the following error which leads me to believe that something is wrong with the tunnel now:

[~]# /usr/local/rvm/gems/ruby-1.9.3-p448@global/gems/rmate-1.5.5/bin/rmate:149:in `readline': end of file reached (EOFError)
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/gems/rmate-1.5.5/bin/rmate:149:in `connect_and_handle_cmds'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/gems/rmate-1.5.5/bin/rmate:186:in `block in <top (required)>'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/gems/rmate-1.5.5/bin/rmate:185:in `fork'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/gems/rmate-1.5.5/bin/rmate:185:in `<top (required)>'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/bin/rmate:19:in `load'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/bin/rmate:19:in `<main>'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/bin/ruby_noexec_wrapper:14:in `eval'
    from /usr/local/rvm/gems/ruby-1.9.3-p448@global/bin/ruby_noexec_wrapper:14:in `<main>'

This bash version is simply giving me no output even with the verbosity flag set.

I also did set /etc/rmate.rc to this for good measure:

port: 52698

Any ideas here as to what may be going on or any way to coax rmate.sh to offer some more insight on the connectivity issue?

user@host:~$ head -5 /etc/hosts
#
# Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# Internet host table

user@host:~$ sudo /tmp/rmate-new.bash /etc/hosts

Buffer opens with only:

#
# Copyrigh

This https://github.com/aurora/rmate/blob/v0.9.9/rmate#L37 now says:

version="0.9.9"
version_date="2017-04-06"

I suppose it should be:

version="0.9.9"
version_date="2017-06-27"

or something similar.

is rmate capable of reading from stdin as vim is?

echo "abc" | vim -

Would be great if we could create a Debian package of this script and distribute it on Debian and Ubuntu via apt-get. I would also love to be able to create a FreeBSD port of it too.

All of these above for easier maintainability on remote servers. Are you planning on introducing versioning for this project? Would be great if there was something we could tie the package versions to.

Cheers,

Attila

it will be awesome if it supports remote directory editing

See #63 for details. This get's implemented by supporting a generic proxy-command that can be optionally specified as command-line argument or configured in the settings file.

v0.9.1

Is there a way to get:
rmate path/to/dir
to handle directories like:
mate path/to/dir

ATM, it seems to open it as a file and, on save, does not do anything on the remote server and there is no error anywhere

thanks!

Hi,

I would really appreciate it if you could resolve the issue I describe below ASAP (I need to be able to use rmate again to run programs for a project with a deadline)

I recently found rmate is no longer working on a remote server, and I thought it might be because of a cross-talk with Jupyter Lab another user is using (on his account, just to be clear. We are not sharing the same account). For instance, when doing "sudo lsof -i tcp:52698" and then killing PIDs that appear from it by "sudo kill -9 [PID]", his Jupyter Lab process got shut down. Now, I wasn't totally sure whether rmate is not working because of the potential cross-talk, but I decided to change the default port number for rmate, 52698 to see if it solves the problem. I first followed jsmedmar's suggestion in https://stackoverflow.com/questions/35343853/how-to-use-sublime-text-over-ssh-with-multiple-computers-in-same-server-using-rs, but it didn't work. And then, I followed the suggestion in "Port Forwarding" section of https://macromates.com/blog/2011/mate-and-rmate/ (with RMATE_PORT=52699 instead of 12345 to be consistent with jsmedmar's suggestion above, but I guess this is not an important detail), but it still didn't work. So, changed all the files I modified back to their original configurations, which are: Packages/User/rsub.sublime-settings (used in the first suggestion; since this file didn't exist before I deleted it), ~/.ssh/config(used in both the first and second suggestions), ~/.bashrc (used in the second suggestion) in my local computer, and ~/.bash_profile (used in the first suggestion), /etc/ssh/sshd_config (used in the second suggestion) in the server. But, still I got the following error message:
/usr/local/bin/rmate: connect: Connection refused
usr/local/bin/rmate: line 412: /dev/tcp/[my IP address xx.xx.xx.xxx]/52699: Connection refused
Unable to connect to TextMate on [my IP address xx.xx.xx.xxx]:52699

In particular, I don't understand why the port number in that error message is still 52699. I tried both "-R 52698:localhost:52698" in the ssh command and adding "RemoteForward 52698 localhost:52698" in ~/.ssh/config, but whatever I do, the port number in the error message was still 52699. Also, I remember when I got a similar error message before I tried the two suggestions above, I got "localhost" in place of [my IP address xx.xx.xx.xxx] in the error message (although I am not totally sure).

I've reinstalled rmate but I still get the exact same error message. My guess is that while trying the first and second suggestions above, I changed RMATE_HOST and RMATE_PORT environment variables explicitly on the server side and this might have made some permanent changes to them. But, at least when I echo those variables they did not return anything. Another guess is that creating a file called "sub.sublime-settings" in Packages/User directory of the local Sublime Text (as suggested by the first suggestion) might have had some affect, but this might be unlikely since when I use a different local computer to try rmate on the remote server, I get the exact same error message.

I looked into /usr/local/bin/rmate file, but I am not familiar with the shell script, and I couldn't figure out what's wrong. At least I could see that the error message I got depends on "$host" and "$port" variables and something must have gone wrong with them.

In any case, if you could give any suggestions to solve this issue and allow me to use rmate again, I would really appreciate that!

Thanks for the excellent script!

A small feature request - I'd like to do something like:

find . -name filename | rmate

Is this something which can be supported easily?

Thanks!

cmdline: rmate -P 30698 /etc/apache2/sites-enabled/my.awesome.site-ssl.conf

actual result:

unable to cd to ../sites-available/my.awesome.site-ssl.conf directory
/usr/local/bin/rmate: line 300: /my.awesome.site-ssl.conf: No such file or directory
cat: /my.awesome.site-ssl.conf: No such file or directory

expected result:
rmate opening and sending the real file the symlink points to

additional info:
symlink points to "../sites-available/my.awesome.site-ssl.conf"

I have been using rmate in all my remote servers. Recently, I've just bought another mac laptop, so I hope I can use rmate on it too.

However, it's interesting if the TextMate is opened on the remote mac, the rmate command will open the TextMate on the remote mac. I have to quit TextMate on the remote mac, so rmate will open the file locally.

I'm wondering if anything I can do to fix this? Thank you :)

I have been trying to get rmate working on remote machines (Mac Pros which also have textmate2 installed). rmate works fine from my macbook when sshing to linux machines but only works intermittently when sshing to mac pros. It took a while but I realized that when I run the rmate command on the remote mac pros, the text file is opened on the remote machine using textmate2! If I quit textmate on the remote machine, then rmate works fine.

My understanding of port forwarding is somewhat rudimentary. When textmate is not running on the remote machine, the port 52698 listeners are (using sudo lsof -P | grep 52698)
sshd 7671 pjkim 13u IPv4 0x398710fcbf7fdb45 0t0 TCP localhost:52698 (LISTEN)

If textmate is running, there are two listeners:
sshd 7671 pjkim 13u IPv4 0x398710fcbf7fdb45 0t0 TCP localhost:52698 (LISTEN)
TextMate 7748 anotheruser 17u IPv6 0x398710fcbb8197ad 0t0 TCP localhost:52698 (LISTEN)

When I run the rmate command, it preferentially is routed (is that the right word) to the local listener and opens textmate2.

I can probably do an ugly workaround by changing the port numbers but that would require a lot of number juggling. Is there an easier way?

When invoking rmate with more than one file location, the script complains:

server# rmate conf/last_httpd.conf conf/last_httpd.include 
dirname: extra operand `conf/last_httpd.include'
Try `dirname --help' for more information.
/root/bin/rmate: line 226: [: conf/last_httpd.conf: 
  binary operator expected

If you look into your code:

58:
host = localhost
....
88:
if [[ "$host" = "auto" && "$SSH_CONNECTION" != "" ]]; then
    echo "HERE"
    host=${SSH_CONNECTION%% *}
fi

You can notice that at line 88 $host is always localhost. It seems this code must be after command line option processing

Hy there I enjoy using rmate a lot.

Actual behaviour

I did run into an issue today:

1. I want to create a new script

    rmate /home/user/bin/myscript.sh
   

2. Rmate opens and I merrily edit the script and test code snippets parallel in a bash line by line

3. I save in TextMate

4. I think all went well, until I realise much later that there was actually no file being created in the desired path. I realise my mistake that there was no folder to begin with where rmate could have saved the file in.

My script was quite short, but this behaviour might turn out to be veeery annoying if I would spend hours working on a file, saving every now and then, thinking the file is actually saved on disk and then realising that all my edits go up in a puff of "/dev/null smoke".

Expected Behaviour

I suggest that rmate will abort the process if the folder is not present. There could also be an option like with mkdir -p /home/user/some/new/folders/that/are/created.
I also do not have a problem with rmate creating folders for me (maybe printing out that it did so).

Please note that for example nano does a good job warning the user that the folder does not exist:

My version of ls is outdated (can’t do anything about that…):

$ ls --version
ls (GNU coreutils) 5.97

rmate in line 295 says:

filesize=`ls -lLn "$realpath" | awk '{print $5}'`

The result with my version of ls is for example 12,345. Then rmate fails by displaying only the N bytes of the number before the , – 12 in this example.

I fixed this by adding the following line after 295:

filesize=$(echo "$filesize" | sed 's/,//')

The ruby version does this: https://github.com/textmate/rmate/blob/master/bin/rmate#L177

Anything over 34624 bytes gets truncated on save for me. Any thoughts on why this might be? Let me know if any further info is needed for reproducing.

I've run the latest version of rmate-sh 0.9.9 (2017-04-06) through shellcheck v0.4.6 https://www.shellcheck.net/ and addressed all the warnings I could.

Mostly the warnings were about:

• more conservative use of double quotes (assignments, args)
• use of backticks for shell evaluation versus newer $(..) syntax
• use of read without "-r" option [may result in mangling of backslashes]
• creation of filepaths var as an array, but expansion & re-assignment as a string
• not handling potential failed cd commands

I'll run things on my machine with the changes for a few days and then make pull requests -- UNLESS someone indicates they think resolving shellcheck warnings is ill advised right now.

I would be nice to have an option to disallow opening same file twice. In big projects, some times I open the same file 2 or 3 times and it is a bit messy.

durr@testcnc:~$ rmate /usr/lib/tcltk/linuxcnc/bin/halshow.tcl
File /usr/lib/tcltk/linuxcnc/bin/halshow.tcl is not writable! Use -f to open anyway.
durr@testcnc:~$ rmate /usr/lib/tcltk/linuxcnc/bin/halshow.tcl -f
File /usr/lib/tcltk/linuxcnc/bin/halshow.tcl is not writable! Use -f to open anyway.
durr@testcnc:~$ rmate -f /usr/lib/tcltk/linuxcnc/bin/halshow.tcl
< file opens >

For shell commands, I generally assume that flags can go anywhere. However, rmate seems to only parse arguments rmate <here> filename.

This is, well, certainly unexpected, if not a huge issue. It'd be nice if arguments to rmate behaved like every other well-behaved command-line tool.

I have a remote file named img 1497837265 - ['Chip-ID' -> 'ESP8266-1175d8', 'Voltage-In' -> '785.00'].jpg.
(Sublime text can view images, so it's convenient to check images using rmate).

Attempting to open this file via rmate fails:

durr@graphical:~/meterocr/UtiliCam/Server/images$ rmate "img 1497837263 - ['Chip-ID' -> 'ESP8266-1175d8', 'Voltage-In' -> '785.00'].jpg"
dirname: invalid option -- '>'
Try 'dirname --help' for more information.
ls: cannot access '/home/durr/img 1497837263 - ['\''Chip-ID'\'' -> '\''ESP8266-1175d8'\'', '\''Voltage-In'\'' -> '\''785.00'\''].jpg': No such file or directory
cat: '/home/durr/img 1497837263 - ['\''Chip-ID'\'' -> '\''ESP8266-1175d8'\'', '\''Voltage-In'\'' -> '\''785.00'\''].jpg': No such file or directory
durr@graphical:~/meterocr/UtiliCam/Server/images$ rmate img\ 1497837263\ -\ \[\'Chip-ID\'\ -\>\ \'ESP8266-1175d8\'\,\ \'Voltage-In\'\ -\>\ \'785.00\'\].jpg
dirname: invalid option -- '>'
Try 'dirname --help' for more information.
ls: cannot access '/home/durr/img 1497837263 - ['\''Chip-ID'\'' -> '\''ESP8266-1175d8'\'', '\''Voltage-In'\'' -> '\''785.00'\''].jpg': No such file or directory
cat: '/home/durr/img 1497837263 - ['\''Chip-ID'\'' -> '\''ESP8266-1175d8'\'', '\''Voltage-In'\'' -> '\''785.00'\''].jpg': No such file or directory
durr@graphical:~/meterocr/UtiliCam/Server/images$

This is trying to either use double-quotes around the entire filename, or the shell's (bash, in my case) automatically escaped filename.

Both these filenames are correct:

durr@graphical:~/meterocr/UtiliCam/Server/images$ file "img 1497837263 - ['Chip-ID' -> 'ESP8266-1175d8', 'Voltage-In' -> '785.00'].jpg"
img 1497837263 - ['Chip-ID' -> 'ESP8266-1175d8', 'Voltage-In' -> '785.00'].jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 0x0, segment length 16, baseline, precision 8, 1600x1200, frames 3
durr@graphical:~/meterocr/UtiliCam/Server/images$ file img\ 1497837263\ -\ \[\'Chip-ID\'\ -\>\ \'ESP8266-1175d8\'\,\ \'Voltage-In\'\ -\>\ \'785.00\'\].jpg
img 1497837263 - ['Chip-ID' -> 'ESP8266-1175d8', 'Voltage-In' -> '785.00'].jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 0x0, segment length 16, baseline, precision 8, 1600x1200, frames 3

Something being done to the filename inside the rmate script is broken by this string, somehow.

The minimal case of this issue is

durr@graphical:~/meterocr/UtiliCam/Server/images$ rmate "test ->.txt"
dirname: invalid option -- '>'
Try 'dirname --help' for more information.

While this project has originally targeted TextMate, I think it's not bad to add necessary links or short guides to use it with other editors, using e.g. rsub for Sublime Text, RemoteSubl for Sublime Text or remote-atom for Atom to README.md.