So i'm trying to move my neovim config over ssh automatically I do this using the following trick in my ssh config:
Host *
SendEnv LC_VIMINIT
RequestTTY yes
RemoteCommand export VIMINIT=$LC_VIMINIT
What I'm doing here is sending the content of the environment variable LC_VIMINIT over ssh and once it's content is moved into the VIMINIT environment variable.
In order to fill the content of LC_VIMINIT I have the following in my fish.config (fish shell)
set -gx LC_VIMINIT (cat ~/.config/nvim/init.vim)
When I connect through ssh and do echo $VIMINIT it works and contains my vim config! When starting neovim however my config is not loaded :(
If I do export VIMINIT='set number' and start neovim it shows line numbers and VIMINIT is properly loaded.
I'm not sure why it's not working, my current hypothesis is that (cat ~/.config/nvim/init.vim) removes the line breaks which causes neovim to ignore it's content?
Maybe someone more experienced can enlighten me?
Put the following in your .ssh/config:
Host *
SendEnv LC_VIMINIT
RequestTTY yes
RemoteCommand export VIMINIT=$LC_VIMINIT
Next put the following in ./config/fish/config.fish:
set -gx LC_VIMINIT (cat ~/.config/nvim/init.vim | grep -P -o '^.*(?=")|^[^"]+$' | awk '{if($1~/autocmd/){ print "execute \""$0"\""} else {print $0}}' | string collect)
What is happening here is that:
The content of ~/.config/nvim/init.vim is stripped from it's comments by grep.
Then each line starting with autcmd is wrapped in execute "<line>"
This is collected into a single string
The string is placed into the LC_VIMINIT environment variable (any LC_* environment variable can be send over ssh).
LC_VIMINIT is send over ssh when connecting to a host because of the setting SendEnv LC_VIMINIT.
Upon connecting to the host the variable VIMINIT is filled with the content of LC_VIMINIT because of RemoteCommand export VIMINIT=$LC_VIMINIT.
I don't think you're going to be able to do what you want. What my copy of Vim says is this:
The value of $VIMINIT is used as an Ex command line.
Notice the article "an". As I read it, you may pass a single command line, not multiple Ex command lines separated by newlines.
You could, of course, try to concatenate them with |, but that won't work for certain Ex commands.
I also don't think you can get a shell and executed a RemoteCommand at the same time, and even if you could, the RemoteCommand would probably be executed in a separate, non-interactive shell.
Most people just create a Git repository and sync their dotfiles that way, which is both easier and more elegant. Of course, that's inconvenient if you're working with many machines, but since I have a custom color scheme and a variety of additional plugins, I just deal with using the defaults in that case.
Related
I have a PS1 varible in bash_profile file as
orange=$(tput setaf 166);
yellow=$(tput setaf 228);
green=$(tput setaf 71);
white=$(tput setaf 15);
bold=$(tput bold);
reset=$(tput sgr0);
PS1="\[${bold}\]";
PS1+="\[${orange}\]\u"; # username
PS1+="\[${white}\]#";
PS1+="\[${yellow}\]\h "; # host
PS1+="\[${green}\]\w"; # working directory
PS1+="\[${white}\]\$ \[${reset}\]"; # '$' (and reset color)
export PS1;
When I open the new terminal instance it's showing everything properly except color.
But, when I execute the command
source .bash_profile
the color is working. It disappears if I open a new tab.
But, In a new terminal instance, without executing the source command,
the color works for
export PS1="\[\033[35m\]\t\[\033[m\]-\[\033[36m\]\u\[\033[m\]#\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "
[
What's the reason for this weird behavior?
In breif, in a new terminal session,
first PS1 is not displaying colors but the second ps1 put in the same bash_profile file is displying it.
But the first one is displaying colors when it is sourced.
Note: I am using mac.
I m also sure that the variable is getting set in bash_profile
but the color is not being set.
You should investigate a little more (yes even more).
In each case you should use printf "%q\n" "$PS1" to see the exact value of the variable PS1 (with escaped unprintable characters). Are you just trying to add the colors to an already set PS1 variable? So, if you get the uncolored output, could that be because your code just wasn't executed so the original value is still set? Then just the PROFILE script isn't executed.
.bash_profile typically only is executed when a login-shell is started. Nowadays many distributions don't get it right and are full of workarounds in this matter, so they often contain .bashrc files which source .bash_profile in their beginning. .bashrc is sourced for each new shell, so effectively, your .bash_profile might well be sourced for each shell as well.
I could guess that your .bashrc first sources .bash_profile and then sets the PS1 to a value like yours, just without the colors. But of course, that's guesswork.
I suspect in the OP's case that using ~/.bashrc rather than ~/.bash_profile to set the colours, is all that is required.
Here is how things work:
There are a number of files involved in setting up your bash environment.
/etc/profile sets the system-wide profile
~/.bash_profile, ~/.bash_login, ~/.profile - These are read by default when bash is invoked as a login shell
~/.bashrc - This is always read unless bash is invoked as sh or bash is invoked as bash --norc
~/.bash_logout - login shell cleanup
~/.inputrc - readline initialisation file.
Which files, and order that these files are read depends on exactly how bash is invoked.
There are a number of cases not all of which are mutually exclusive:
login shell
interactive shell
non-interactive shell
posix mode
bash invoked with stdin connected to network connection (yes
it will know)
bash invoked as sh
bash is invoked with the effective uid/gid not equal to the real uid/gid
You need to be aware of which cases apply to your invocation in order to determine which files will be read.
man bash and search for invocation, for the exact details.
I had installed solarized color scheme/theme for my xterm-256 terminal. It was the one causing the issue. When I change the color scheme, the PS1 is working perfectly.
Accordingly to ssh man page -o allows to set the content of a given ssh client option. I would like to unset SendEnv (or set it to empty) in order to avoid locale setup in server side.
I got the desired effect by commenting SendEnv line in ssh_config file. However, it is not a good option for my application.
How to achieve this when running ssh command? I tried ssh -o SendEnv='' server without success.
It is not possible to do that on the command-line. The SendEnv option does not overwrite, but append to the existing values.
But you can create a different configuration file, which will not have these options and use -F option, which will prevent using the global configuration file:
ssh -F /my/specific_ssh_config server
A bit late but maybe someone can still profit from my answer. According to 'man ssh_config' it is possible to clear SendEnv variables:
It is possible to clear previously set SendEnv variable names by prefixing patterns with -.
So you should basically be able to use your construct with
-o SendEnv=''
But instead of leaving the brackets empty you put the variables which you want to overwrite in the brackets but prefix each of them with a dash.
Or you specify the same in your users own ssh config (usually ~/.ssh/config). Wich if I understand the documentation correctly should also overwrite it.
I am unable to run a remote shell script located on "admin" server with arguments.
ssh koliwada#admin "~/bin/addautomaps $groupentry $homeentry $ticket"
"groupentry" and "homeentry" are as follows
user1:*:52940:OWNER-user1
user1 -rw,intr,hard,rsize=32768,wsize=32768 basinas01:/ifs/basinas01/home/&
the script is located at ~/bin/addautomaps in admin server.
I see the error,
tput: No value for $TERM and no -T specified
I also see the arguments also are not passed correctly.
I also tried using "ssh -t ..." but that doesnt work.
Answering your questions in reverse order (or most serious to least serious).
Your problem with the arguments (with spaces) not being passed correctly is that while you are quoting the command string locally you aren't quoting them when they are actually run by the remote machine.
That is you are generating a single string with the variables expanded but nothing tells the remote system not to split the expanded values on spaces.
The fix for that is that you need to quote the arguments inside the command for the remote shell as well as the entire string for ssh.
My answer here might help explain some (it is a similar issue).
The tput "issue" is likely just a warning that you can probably ignore if you don't care about the colorized/stylized/etc. output that tput is likely being used to create. You could also try forcing a value for $TERM on the remote side like ssh ... "export TERM=dumb; ..." or something like that to silence it.
I've been editing .bashrc files and other init files, and it seems that I've left behind a few code snippets or two that are causing a few errors at the prompt (e.g. file missing), but I can't find them.
How do I debug the prompt to find out what init scripts I've carelessly hacked?
Most of the shells have debug flags that show the commands being executed. Bash may even have one that shows a command before expansion of variables and after. Have you tried checking (I believe) -c -x or -X flags and see if they show the information you are looking for.
You can set them as first thing in the rc files (most global one) or just pass it down into bash command by invoking it from another shell.
In fact, if you invoke bash from another shell, you can also use script command to record everything you see and do into the file, which makes postmortem analysis so much easier.
Try invoking bash with the -x flag, then sourcing your .bashrc or .bash_profile or whatever you're using. That ought to be prolix enough to find your problem
ie:
bash -x
source .bashrc
The easiest way to get a clean initial state is to SSH into your current host, but instead of letting SSH launch your shell with default settings, you provide an explicit command which prevents .bashrc from being read.
ssh -tt localhost /bin/bash --norc
The -tt forces SSH to allocate a TTY, which is what would normally happen when you open a shell connection, but is not default when running an explicit command.
The --norc prevents bash from reading your settings file (since we want to do that ourselves).
You should now be at a bash prompt, in a clean environment. This is useful for examining what variable are set to before your .bashrc runs etc. Enable tracing and source your .bashrc:
set -x # Enable tracing
source .bashrc
Try to see where you've defined prompt - probably it in some dot file in your home directory:
grep PS1 ~/.*
You can see current value of prompt by just printing it:
echo $PS1
HTH
Check the .bash_history file in your home directory to find out what commands you have been running. If you used commands like vi filename to open the init scripts, it will find them in the command history.
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.