Explorer does not honour port number when editing over SCP

17 views
Skip to first unread message

guyht

unread,
Aug 29, 2011, 12:44:26 PM8/29/11
to vim_dev
I am experiencing a bug where Explorer does not honour a port number
when editing files over SCP.

To reproduce

Open a directory over scp (gvim scp://user@domain:1234//home/user/)

Files and directories listed as expected...

Open a file

vim ignores the port number and attempts to edit the file at
scp://user@domain:22//home/user/file.txt

Charles Campbell

unread,
Aug 30, 2011, 10:51:01 AM8/30/11
to vim...@googlegroups.com

Hello,

The machines I use to test netrw+scp use port#22, so what I did was

scp://user@domain:22//home/user/somefile

This worked, giving me the contents of the file.

scp://user@domain:32//home/user/somefile

This does not work. The "22" was extracted properly by NetrwMethod()
from the first example I gave above. So, I cannot seem to duplicate
your problem and will need your help. Please read :help netrw-debug to
generate a debugging trace when you attempt to open a file via the
non-default port number.

Regards,
Chip Campbell


Benjamin R. Haskell

unread,
Aug 30, 2011, 11:33:03 AM8/30/11
to vim...@googlegroups.com

It appears we both missed something, as I also thought this was a
"worksforme".

The problem is not with opening an individual file. It only occurs when
opening a file from the directory listing.

If I open:

scp://bhas...@example.com:443//home/bhaskell/

The listing is appropriately routed via port 443 (which I use as a
workaround for firewalls that block SSH port 22, but not HTTPS port
443).

But, if I hit Enter on .vimrc in that directory, it opens:

scp://bhas...@example.com//home/bhaskell/.vimrc

(falling back to the default port, not port 443)

I'm using Netrw v141n

If you're in control of any of your test machines, you can simply add
a second 'Port' line to /etc/ssh/sshd_config and restart sshd.

E.g. to listen on both 22 and 443:
Port 22
Port 443

--
Best,
Ben

Guy Halford-Thompson

unread,
Aug 30, 2011, 11:46:38 PM8/30/11
to vim...@googlegroups.com
Ah, sorry I wasn't too clear in my first post, thanks for clarifying.

Unfortunately I can't change the sshd_config, going to have to work
around it for the moment.

Is this something that is likely to get fixed?

Ty

> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>

--
Guy Halford-Thompson
Blog                  - http://www.cach.me/blog
Twitter               - https://twitter.com/mrwooster
Google Plus       - http://gplus.name/guy

Lech Lorens

unread,
Aug 31, 2011, 6:08:50 AM8/31/11
to vim...@googlegroups.com
On 31 August 2011 05:46, Guy Halford-Thompson <g...@cach.me> wrote:
> Ah, sorry I wasn't too clear in my first post, thanks for clarifying.
>
> Unfortunately I can't change the sshd_config, going to have to work
> around it for the moment.
>
> Is this something that is likely to get fixed?

Please, quote only the relevant parts of the conversation you are referring to.

I believe that the suggestion about changing sshd_config was for Dr Chip.

With regard to your problem, you can probably work it around by specifying
in your ~/.ssh/config that the server you are connecting to uses a non-default
port. It would be something like (I'm writing from memory, forgive me if I'm
wrong. Check out "man ssh_config"):

Host your.server.ip.or.name.com
Port 1234

For me personally it would actually be much more convenient than having to
specify the port during every scp/ssh invocation.

--
Cheers,
Lech Lorens

Benjamin R. Haskell

unread,
Aug 31, 2011, 8:26:34 AM8/31/11
to vim...@googlegroups.com
On Tue, 30 Aug 2011, Guy Halford-Thompson wrote:

> Ah, sorry I wasn't too clear in my first post, thanks for clarifying.

No problem.


My turn to clarify, it seems:

> Unfortunately I can't change the sshd_config, going to have to work
> around it for the moment.

I wouldn't expect you to. That suggestion was in response to Dr. Chip's
lead-in:

>>> The machines I use to test netrw+scp use port#22,

> Is this something that is likely to get fixed?

Seems very likely to me. And probably soon, based on his usual
turnaround time.

--
Best,
Ben

Benjamin R. Haskell

unread,
Aug 31, 2011, 9:20:06 AM8/31/11
to vim...@googlegroups.com

As far as I can tell, the source of the issue is that
autoload/netrw.vim's s:NetrwBrowse calls:

(line 2439 in v141n):

sil call netrw#NetRead(2,s:method."://".s:user.s:machine."/".s:path)

Note the lack of any port numbers. When running my example (with :443),
the dirname variable in that section properly contains that :443 and
g:netrw_port is set to 443, but it's not being used.

The easiest fix would be to use something like:

let url = s:method."://".s:user.s:machine.(s:port ? ":".s:port : "")."/".s:path

and replace the two occurrences around line 2439 of:
s:method."://".s:user.s:machine."/".s:path

with:
url

This worked for me, so, patch attached.

--
Best,
Ben

netrw-v141n-scp-port.patch

Benjamin R. Haskell

unread,
Aug 31, 2011, 9:26:15 AM8/31/11
to vim...@googlegroups.com
On Wed, 31 Aug 2011, Lech Lorens wrote:

> On 31 August 2011 05:46, Guy Halford-Thompson wrote:
>> Unfortunately I can't change the sshd_config, going to have to work
>> around it for the moment.
>

> With regard to your problem, you can probably work it around by
> specifying in your ~/.ssh/config that the server you are connecting to
> uses a non-default port. It would be something like (I'm writing from
> memory, forgive me if I'm wrong. Check out "man ssh_config"):
>
> Host your.server.ip.or.name.com
> Port 1234
>
> For me personally it would actually be much more convenient than
> having to specify the port during every scp/ssh invocation.

Yes. That's a good workaround.

Even better would be to give your.server.ip.or.name.com a shorter name.

For example, I have something like:

Host home
HostName your.server.ip.or.name.com
Port 443

Then the very short 'scp://home/.vimrc' is my .vimrc in my home dir on
your.server.ip.or.name.com over port 443

And the shortname is available via OpenSSH commands:

ssh home
scp file1 file2 home:

--
Best,
Ben

Charles Campbell

unread,
Aug 31, 2011, 10:25:48 AM8/31/11
to vim...@googlegroups.com
I'll look into it. Been busy lately....
Regards,
Chip

Charles Campbell

unread,
Aug 31, 2011, 10:44:12 AM8/31/11
to vim...@googlegroups.com, Charles Campbell
The patch looks good, so I'll include it. The latest netrw is available
for testing (which incorporates that patch) is available at my website:
http://drchip.0sites.net/astronaut/vim/index.html#NETRW (v143h).

Regards,
Chip Campbell

Guy Halford-Thompson

unread,
Aug 31, 2011, 1:31:54 PM8/31/11
to vim...@googlegroups.com
On 31 August 2011 07:44, Charles Campbell <Charles.E...@nasa.gov> wrote:
> Charles Campbell wrote:
>>
>> Benjamin R. Haskell wrote:
>>>
>>> On Wed, 31 Aug 2011, Benjamin R. Haskell wrote:
>>>
>>>> On Tue, 30 Aug 2011, Guy Halford-Thompson wrote:
>>>>
>>>>> Is this something that is likely to get fixed?
>>>>
>>>> Seems very likely to me.  And probably soon, based on his usual
>>>> turnaround time.
>>>
>>> As far as I can tell, the source of the issue is that
>>> autoload/netrw.vim's s:NetrwBrowse calls:
>>>
>>> (line 2439 in v141n):
>>>
>>> sil call netrw#NetRead(2,s:method."://".s:user.s:machine."/".s:path)
>>>
>>> Note the lack of any port numbers.  When running my example (with :443),
>>> the dirname variable in that section properly contains that :443 and
>>> g:netrw_port is set to 443, but it's not being used.
>>>
>>> The easiest fix would be to use something like:
>>>
>>> let url = s:method."://".s:user.s:machine.(s:port ? ":".s:port :
>>> "")."/".s:path
>>>
>>> and replace the two occurrences around line 2439 of:
>>> s:method."://".s:user.s:machine."/".s:path
>>>
>>> with:
>>> url
>>>
>>> This worked for me, so, patch attached.

Just installed the patch and it works great.

Thanks for fixing so quickly

Reply all
Reply to author
Forward
0 new messages