I want to bind a command to a key-combination in zsh, which is different on OSX and Linux. My current state is
if [[ "$(uname)" == "Darwin" ]]; then
bindkey "^e" some-command # Ctrl+E for OSX
else
bindkey "^[e" some-command # Alt+E for Linux
fi
However, this does not work for ssh connections between those two systems. So actually, I don't want to check in which OS my shell runs in, but rather in which OS my terminal runs in. Is there a way to get that information?
Please don't focus on the details of the keys used in the binding. That's not relevant at this point :)
Edit:
To make things clearer:
The terminal is the thingy, you type your commands in, like Iterm2, Guake or Xterm
The shell is the thingy, that receives and executes the commands like Bash, Zsh or Fish
ssh can send environment variables to the server and does this by default for handful of variables. Although any information on the clients operating system is not part of that default list, it can be extended.
You need to set and export a variable that has the needed information. You can go with the output of uname or you could just copy OSTYPE (You should not use OSTYPE directly, as changing it may not be a good idea). So you need something like this in your ~/.zshrc on both systems (somewhere on top before you need it, of course):
export CLIENT_OSTYPE=${CLIENT_OSTYPE:-$OSTYPE}
This sets CLIENT_OSTYPE to the value of OSTYPE if it was previously unset. So if you log in locally, it will be the set to OSTYPE. But if you log in with ssh it will be set to the CLIENT_OSTYPE that was passed along.
Now you have to set your SSH Clients to actually pass CLIENT_OSTYPE to the server. For that you need to edit the SendEnv entry ssh client configuration - either user specific (~/.ssh/config) or globally (Most likely /etc/ssh/ssh_config on Linux, /etc/ssh_config on Mac):
SendEnv CLIENT_OSTYPE
It may already be set to some value in the global configuration (LANG LC_* in my case), in that case just add to the list:
SendEnv LANG LC_* CLIENT_OSTYPE
Finally, you have to configure the SSH servers to actually accept this environment variable. This can be done in /etc/ssh/sshd_config on Linux and /etc/sshd_config on Mac by modifying AcceptEnv:
AcceptEnv CLIENT_OSTYPE
Similar to SendEnv this may also already be set to something:
AcceptEnv LANG LC_* CLIENT_OSTYPE
You then can use the value of CLIENT_OSTYPE to decide which configuration you want to use.
I'm thinking that the shell command arch might help you out here.
It will also tell you whether you are on a 32-bit or a 64-bit MacOS machine.
Related
I am trying to setup svn over ssh on an OS X server. In order to do so, I read that I need a wrapper to set umask and - in my case - to set the repository root. A quick and dirty way to do that is to rename /usr/bin/svnserve and place a wrapper script at that location. However SIP protects that location from any changes, and I would prefer a cleaner solution anyway.
So I created a wrapper script at /usr/local/bin/svnserve and created /etc/ssh/sshrc with
PATH=/usr/local/bin:$PATH
I have verified that this file gets executed when initiating a remote ssh command from my client by writing to a log file. However, the modified PATH does not seem to get passed to the command environment:
ssh hostname 'echo $PATH'
Password:
/usr/bin:/bin:/usr/sbin:/sbin
Am I overlooking something? Or is /etc/ssh/sshrc the wrong place to set a path? If so, what's the right place?
Other places I've tried: /etc/profile and /etc/bashrc, but none of these seem to get executed in connection with an ssh command.
Note: It is not an option to change the client behavior (like, for example, adding the desired path to the command).
/etc/sshrc does not run in the same shell instance with the remotely-issued command, so the PATH update does not persist through.
Some of the available options:
You can set AcceptEnv PATH on the server to configure it to accept a PATH sent by the remote system, and SendEnv PATH on the client (in ~/.ssh/config, or as an argument to ssh passed with -o, or in /etc/ssh/ssh_config).
In /etc/ssh/sshd_config on the server, you can set the option PermitUserEnvironment to yes; with that done, the variable and value can be added to ~/.ssh/environment in the individual user's account on the server.
You can use ForceCommand to override the remotely requested command, either with something like /usr/bin/env PATH=/usr/local/bin:/usr/bin:/bin svnserve or simply /usr/local/bin/svnserve
I couldnt find answer to this althougth there are many similar questions.I wanted to change colour of my linux command prompt based on the remote host i have ssh to.Since bash environment variables are not preserved over ssh,so how could i do this.There are hundreds of server i login everyday.So changing /.bashrc of each remote host is not possible.is there a way i can pullout a script which can be called each time ssh is done.Can someone please give in detail of which file and how it should be edited.gnome,openssh etc are not supprted.
during ssh execution,a new login shell was executed.
during shell login the *rc files are not executed,only *profile was executed.
so place your code in /etc/profile or ~/.bash_profile.
"Since bash environment variables are not preserved over ssh..."
man ssh
Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
“VARNAME=value” to the environment if the file exists and users are
allowed to change their environment. For more information, see the
PermitUserEnvironment option in sshd_config(5).
When I run gvim from MSYS, things go wrong during initialization. Namely, gvim can't find the initialization files that are in 'C:\Documents and Settings\username\vimfiles.
[Specifically, gvim reports the error E117: Unknown function: pathogen#infect during initialization, so it never found autoload\pathogen.vim. Doing :scriptnames also confirms that none of the setup files from vimfiles\ are run.]
I think I've debugged why it goes wrong. When you start MSYS, the MSYS shell inherits the windows enviroment variables, but changes some of them to it's custom values. C:\Documents and Settings\username is the value of $HOME in Windows, but MSYS sets it to something like C:/msys/user name. And of course, Vim uses $HOME to find the right initialization files.
I also notice set shell? has changed to something like shell=C:/msys/bin/sh instead of shell=C:\WINDOWS\system32\cmd.exe, but I hope this isn't important for fixing the initialization problem.
I need to run gvim with the normal windows environment variables. At least I need to be able to manually override a few important ones like $HOME to something I specify (i.e., I'm not concerned about my windows $HOME changing, so it's fine to use a static value).
I tried to reset $HOME manually in my vimrc, but by then it is too late.
Is there some trick to specifying $HOME early on during initialization, or as an extra command line parameter?
Alternatively, is there some trick with running commands from msys differently? I know almost nothing about how the shell C:/msys/bin/sh works, but I could conceive of some extra arguments that changes the visibile environment for the command (e.g. gvim.exe) you are typing.
---Edit---
Reposting the solution that worked (it achieves the later idea):
Instead of running gvim.exe, run the command HOME="C:\Documents and Settings\username" gvim.exe
In bash and other UNIX shells, you can do:
$ HOME='/path/to/dir' gvim
to temporarily set $HOME to a different value.
I admit I'm not familiar at all with the Windows command line, but it might be worth a try.
I believe you can define $HOME just like any other environment variable.
Try adding this to the start of your .vimrc.
let $HOME="C:\Documents and Settings\username"
I had a similar issue when running Cygwin (which is similar to MSYS).
The easiest solution for me was to simply set the HOME environment variable to an empty string. Otherwise, the Cygwin HOME value would be appended to the Windows USERPROFILE in GVim and it would fail to start correctly. Not explicitly setting the full path of the HOME means that I can use the same start-up files on different systems where the USERNAME may not be the same.
Likewise, the SHELL environment variable should not be inherited from Cygwin Bash. This results in errors when running shell or external programs via !. Again, I set this to be an empty variable since Vim is smart enough to figure out what it should be.
In my .bashrc, I set the following alias for running Windows gvim which starts GVim with the HOME and SHELL variables set to an empty string – just for that command.
gvim="/cygdrive/c/Program Files (x86)/Vim/vim74/gvim"
if [ -x "$gvim" ]; then
alias gvim="HOME= SHELL= \"$gvim\""
fi
unset gvim
I achieved this by making a windows symbol link (Win 7 or higher).
Via a symbol link, you can even make vim and gvim to use the same configuration and plugin.
I try to start some command from ssh non-interactive ssh connection. I use ant-sshexec connection for that.
In order to set everything up I used this article:
http://www.raphink.info/2008/09/forcing-environment-in-ssh.html
I use ~/.ssh/environment.
In order to do that, I set PermitUserEnvironment to "yes" in sshd_config and restarted sshd.
In my .ssh/environment I have this content:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/ubuntu/java/jdk1.6.0_27/bin
JAVA_HOME=/home/ubuntu/java/jdk1.6.0_27
#PATH=/home/ubuntu/java/jdk1.6.0_27/bin:$PATH
#PLAY_HOME=/home/ubuntu/play
and I have the error when try to connect using non-interactive connection:
[sshexec] Could not execute the java executable, please make sure the JAVA_HOME environment variable is set properly (the java executable should reside at JAVA_HOME/bin/java).
But I added the java to the path..
The man page for sshd(8) says this about ~/.ssh/environment:
It can only contain empty lines, comment lines (that start with
‘#’), and assignment lines of the form name=value.
That is, it is not a shell script at all. You have double quotes, variable expansion and an alias definition. None of that will work. Try this:
PATH=/home/ubuntu/java/jdk1.6.0_27/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
JAVA_HOME=/home/ubuntu/java/jdk1.6.0_27
PLAY_HOME=/home/ubuntu/play
Also ensure that the permissions on the ~/.ssh/environment are as described in the man page — no group or other write permissions on the file.
If you are concerned with locking yourself out of the account with a broken environment, test by logging onto the host first and running test commands such like this:
ssh localhost 'echo $JAVA_HOME'
You can ensure that the environment variables are set as you expect them and if something goes wrong, you are still logged onto the host allowing you to reverse your changes.
You used multiple environement variable for path . But don't export from command what i see.
You should do it like that way.
export PATH="A"
export PATH="$PATH:B"
export PATH="$PATH:C"
Also you can get this type of help from there.
So please post it to unix.
https://unix.stackexchange.com/questions/12391/how-to-run-my-c-program-from-anywhere-within-the-system-ubuntu-10-10
Hope it helps.
Can I have certain settings that are universal for all my users?
As well as /etc/profile which others have mentioned, some Linux systems now use a directory /etc/profile.d/; any .sh files in there will be sourced by /etc/profile. It's slightly neater to keep your custom environment stuff in these files than to just edit /etc/profile.
If your LinuxOS has this file:
/etc/environment
You can use it to permanently set environmental variables for all users.
Extracted from: http://www.sysadmit.com/2016/04/linux-variables-de-entorno-permanentes.html
man 8 pam_env
man 5 pam_env.conf
If all login services use PAM, and all login services have session required pam_env.so in their respective /etc/pam.d/* configuration files, then all login sessions will have some environment variables set as specified in pam_env's configuration file.
On most modern Linux distributions, this is all there by default -- just add your desired global environment variables to /etc/security/pam_env.conf.
This works regardless of the user's shell, and works for graphical logins too (if xdm/kdm/gdm/entrance/… is set up like this).
Amazingly, Unix and Linux do not actually have a place to set global environment variables. The best you can do is arrange for any specific shell to have a site-specific initialization.
If you put it in /etc/profile, that will take care of things for most posix-compatible shell users. This is probably "good enough" for non-critical purposes.
But anyone with a csh or tcsh shell won't see it, and I don't believe csh has a global initialization file.
Some interesting excerpts from the bash manpage:
When bash is invoked as an interactive
login shell, or as a non-interactive
shell with the --login option, it
first reads and executes commands from
the file /etc/profile, if that file
exists. After reading that file, it
looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that
order, and reads and executes commands
from the first one that exists and is
readable. The --noprofile option may
be used when the shell is started to
inhibit this behavior.
...
When an
interactive shell that is not a login
shell is started, bash reads and
executes commands from
/etc/bash.bashrc and ~/.bashrc, if
these files exist. This may be
inhibited by using the --norc option.
The --rcfile file option will force
bash to read and execute commands from
file instead of /etc/bash.bashrc and
~/.bashrc.
So have a look at /etc/profile or /etc/bash.bashrc, these files are the right places for global settings. Put something like this in them to set up an environement variable:
export MY_VAR=xxx
Every process running under the Linux kernel receives its own, unique environment that it inherits from its parent. In this case, the parent will be either a shell itself (spawning a sub shell), or the 'login' program (on a typical system).
As each process' environment is protected, there is no way to 'inject' an environmental variable to every running process, so even if you modify the default shell .rc / profile, it won't go into effect until each process exits and reloads its start up settings.
Look in /etc/ to modify the default start up variables for any particular shell. Just realize that users can (and often do) change them in their individual settings.
Unix is designed to obey the user, within limits.
NB: Bash is not the only shell on your system. Pay careful attention to what the /bin/sh symbolic link actually points to. On many systems, this could actually be dash which is (by default, with no special invocation) POSIXLY correct. Therefore, you should take care to modify both defaults, or scripts that start with /bin/sh will not inherit your global defaults. Similarly, take care to avoid syntax that only bash understands when editing both, aka avoiding bashisms.
Using PAM is execellent.
# modify the display PAM
$ cat /etc/security/pam_env.conf
# BEFORE: $ export DISPLAY=:0.0 && python /var/tmp/myproject/click.py &
# AFTER : $ python $abc/click.py &
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
abc DEFAULT=/var/tmp/myproject