As a fallback, use "ssh -G" to get host config.

[twrecked]

Along with include directives I have ssh configuration entries like this:

Host laptop*
	Hostname 192.168.1.146
	IdentityFile ~/.ssh/roger
	User roger

Host desktop*
	Hostname 192.168.1.147

Host server*
	Hostname 192.168.1.148

Host *x
	ForwardX11 yes

Host *
	IdentitiesOnly yes
	User dave
	IdentityFile ~/.ssh/dave
	ServerAliveInterval 15
	StrictHostKeyChecking ask
	ForwardX11 no

So, for example, I can 'ssh desktop' to connect without X support and 'ssh desktopx' to connect with X support. netman can't parse this and attempting to connect to sftp://desktop/README will throw an error.

This PR will fall back to ssh -G <host> (and lets ssh parse its configuration file) if netman can't find the host.

A couple of things:

• lua is new to me.
• Likewise nvim.
• I feel like this should be a configurable option but I'm not sure how to go about adding config, I'll look some more into that.

Thanks for the great plugin.

[miversen33]

I'm going to have to marinate on this one.

I think the idea is good, but my ssh config parsing logic is already not amazing so I need to verify that your change won't break anything.

I feel like this should be a configurable option but I'm not sure how to go about adding config, I'll look some more into that.

Netman isn't designed to be configurable really. The idea is that it "just works". There are an extremely limited amount of configuration options you can provide it (such as log level), and that is explicitly because netman was intended to be a framework for other tools.

That never really took off, but the idea should still remain the same. I like the idea here, I just need to validate that its the right way of handling.

This PR will fall back to ssh -G (and lets ssh parse its configuration file) if netman can't find the host.

A thing to keep in mind is that netman needs to work on Linux, Windows and Mac. I haven't investigated ssh too terribly much on Windows, but we want to make sure that -G behaves identically on Windows. If it doesn't, we will need branching logic based on OS. Not something that can't be done, just something to keep in mind here.

[twrecked]

I understand completely. And I'm quite happy just to patch my install for now. I figured it was worth sharing just in case. Thanks, Steve

…

On Wed, Jul 30, 2025, 22:34 Mike Iversen ***@***.***> wrote: *miversen33* left a comment (miversen33/netman.nvim#213) <#213 (comment)> I'm going to have to marinate on this one. I think the idea is good, but my ssh config parsing logic is already not amazing so I need to verify that your change won't break anything. I feel like this should be a configurable option but I'm not sure how to go about adding config, I'll look some more into that. Netman isn't designed to be configurable *really*. The idea is that it "just works". There are an extremely limited amount of configuration options you can provide it (such as log level), and that is explicitly because netman was intended to be a framework for other tools. That never really took off, but the idea should still remain the same. I like the idea here, I just need to validate that its the right way of handling. This PR will fall back to ssh -G (and lets ssh parse its configuration file) if netman can't find the host. A thing to keep in mind is that netman needs to work on Linux, Windows and Mac. I haven't investigated ssh too terribly much on Windows, but we want to make sure that -G behaves identically on Windows. If it doesn't, we will need branching logic based on OS. Not something that can't be done, just something to keep in mind here. — Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHJU6V4NTVGND656TKPT7D3LF6DDAVCNFSM6AAAAACCX7UC5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMZYGM3TCMRRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>