Then parse $ for the you derived from step#1, and in that record find the new command "#!source "īut I really can't think of a use-case that would require such a binary wrapper to do anything other than set environment variables to fixed values. (parse) actually not that bad, only needs special treatment, discard all other -options and catch the first non-option argument which is or I really wanted a "do anything" setup, it would involve executing a binary with the the original SSH command, but also with an additional command-line switch to exclude running the binary wrapper (to avoid recursive binary wrapper execution). I have a use-case for setting environment variables, but I'm not too sure I have a solid use-case for anything else. what all would you want to be able to modify about the runtime environment based on the contents of the SSH config? What sucks a bit is duplicating all the parameter&option parsing syntax/semantics of ssh cmdline since I hate running into them a second time -)Ī wrapper script should be versatle and simple enough to even be fun to implement Hmmmmm, you could get a wrapper script around the `ssh` binary, to parse your ~/.ssh/configĪcdimalev: ack, but I *love* solving problems for good. It sounds like you're dealing with a single device? In that case, definitely do not trouble yourself with an effort besides correcting that single instance. I know you can define binaries to execute regardless of commandline, on ssh *server* side in the pubkey recordĪ pity that despite it sounds very similar, it doesn't apply at all for this usecase In the days where my server logins were single digit and automated server builds were not a thing, it made sense to try and adjust everything server-side. It would be useful for way more than just setting up a term. The latter should cover the former, sourcing instead of exec'ing the script `SetEnv TERM xterm` in `~/.ssh/config` is what I'm thinking. It would be incredibly useful to be able to specify environment variables for a specific SSH host. Not that I have time to look into it at the moment, but that does make me wonder how difficult it would be to add support for such an option to Open SSH. I don't think the sane defaults are going to meet your expectations.ĭamn, I should write a ssh alias that copies my complete "environment" like ~/.profile ~/.aliases ~/bin etc pp, on *each* login -) Just run `unset TERM` on a local terminal and try a few things. Hmmm, I guess when I do NOT forward xterm-256color then the target system falls back to sane? I wish it did, and if anybody can point out an oversight on my behalf, I'd be delighted. The SSH config file controls which environment variables get forwarded, but I haven't seen any options for setting environment variables. I mean, _all_ my ssh logins have a record in my ssh config I've had to deal with this problem ever since I adopted a terminal emulator that doesn't set `TERM` to either `xterm` or `xterm-256color`. Thanks, it sounds very reasonable approach
"future update" sounds a tad funny for this particular case: maemo5
CRITICAL ERROR WHEN RUNNIN GUAKE UPDATE
For anything that I do manage, I would be tempted to either backport a package, or look ahead at where a future update will dump the terminfo file and just drop a copy there.
bashrc or ssh logon or whatever (and what/where, then), or revert&fix back to plain TERM=xterm on all "new" systems, or only with ssh client of those "new" systemsĭocScrutinizer51: For dealing with large-scale infrastructure that I don't manage, I've found setting up an SSH alias that sets `TERM` to be very effective.
"Fix" my old systems that need TERM=xterm, with a & TERM=xterm, somewhere in. I wonder what's the canonical way to deal with this now.
Oops sorry, I hit "paste" instead of "edit"ĪIUI there's a linux world wide move from TERM=xterm to TERM=xterm-256color, across all distros, maybe started by - alas some "old" systems don't like that move so you get hiccups when you log in to those from a system whose ssh exports a TERM=xterm-256color, see above old Iron900 maemo system damn, did "recent" ssh client updates (+ related libs) cghange the environment and/or behavior of *server* where I log in to with this ssh client? E.G. Been trying to get colors properly setup, but mate is yet again being silly.