Hey. It would be nice, if ssh’s -G could output the key/value pairs for unknown options, e.g. with some prefixed _ or so, to put them into a separate "namespace". The idea is that it would greatly allow one to use ssh -G as a config parser in scripts. If one had something like Host foo IgnoreUnknown MyOption MyOption value yes Then one could use ssh -G to get the right value of MyOption (and whether it's set) out-of-the-box... without needing to care on any things like selecting the right Host or Match block, etc.. Cheers, Chris.
(In reply to Christoph Anton Mitterer from comment #0) > The idea is that it would greatly allow one to use ssh -G as a > config parser in scripts. > > If one had something like > Host foo > IgnoreUnknown MyOption > MyOption value yes I don't think this would be feasible in the current parser without a significant rewrite. The ssh -G works is that the parser runs as normal, filling the Options structure which is then dumped to stdout. It's not general purpose parser. I also don't see what the use case for this would be. Could you give an example?
I'm writing a small wrapper tool (which tries to do the wrapping in a particularly "clean" way) around ssh (and ideally also sftp/scp). Right now it reads a: setenv OpenSSHWrapperCommand="something" (via ssh -G) from ssh_config, and when something comes out of that, it `eval`s that... otherwise it `exec`s ssh "$@" . Then I'll add further such commands, specific for ssh, sftp, scp (and OpenSSHWrapperCommand) just being the "default" for all of them. If -G were to print out unknown commands (which I've asked for in another ticket, IIRC) I could directly use a command name for that, which users would need to add to IgnoreUnknown. Now there are several possible use cases, basically anything which needs to be done locally, but for which LocalCommand doesn't suite. E.g. it might be handy to set up env vars, which are then transmitted via SendEnv. Or we have nodes which are reachable via VPN (even with ssh... don't ask me for the sense in that ^^) ... so the wrapper could initiate that before. Obviously it would be even better to have such functionality in ssh itself, but I guess you'd rather consider it bloat. But having some help in parsing would still be nice,...