I am trying to compile a code from within neovim (using ':make').
But it turns out that neovim does not take into consideration the PATH variable with which neovim has been invoked - neovim uses instead the PATH variable that is set by the .tcshrc script.
More explicitly :
in .tcshrc , PATH variable contains the path /usr/bin.
I update PATH manually (PATH=/mynewversionofgcc/bin:$PATH) prior invoking neovim.
Doing this, I was hoping that the ':make' command would have used gcc that is located into /mynewversionofgcc/bin.
It turns out that it is gcc located into /usr/bin that is being used instead.
Going further :
the command :call system("echo $PATH > foo") shows that PATH in the subshell is not the same as the path of the environment in which neovim has been invoked. (as if .tcshrc was run prior the shell command).
Whereas the command :echo luaeval('os.getenv("PATH")') returns the PATH that is exactly the same as the one of the term where nvim is launched.
Is there a way to get the same PATH inside the subprocess without modifying .tcshrc ?
Related
This is bothering me more than it should and has me completely stumped. I feel like like finding the answer will have some good learning opportunities so hopefully it's relevant.
I do embedded C development with Vim and have a setup for hobbyist stuff with Arduino (using Arduino Makefile). I use :make with some shortcuts with build projects.
An external define resolves the Arduino Makefile root directory in the project level Makefile: 'ARDMK_DIR=/usr/local/opt/arduino-mk'. This is define as an export in my shell (zsh). This is where it gets weird:
Using make at the shell prompt the project builds fine:
make -d
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/opt/arduino-mk/Arduino.mk' (search path) (no ~ expansion)...
However using :make in Vim the define becomes something from an old install:
:make
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk' (search path) (no ~ expansion)...
Makefile:24: /usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk: No such file or directory
I cannot for the life of me find where ARDMK_DIR is being re-defined to '/usr/local/Cellar/arduino-mk/1.5.2'. Things I have tried:
setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\: echo comes back with my shell define (/usr/local/opt/arduino-mk), but make fails with the error above!!
:echo $ARDMK_DIR: again returns my shell define.
ag my home directory for ARDMK_DIR, the only place it is defined is in my shell exports. Did since for my root directory to and same thing. Same thing for $VIMRUNTIME
Even vim-disptach works fine calling the same makeprg?!
Re-define ARDMK_DIR in the project Makefile. Everything builds find as expected. I don't want to do this however as I compile with different systems.
The same vim config works on other macOS and Linux systems with expected behaviour.
Some where between echo and the actual execution of make, ARDMK_DIR is being re-defined. Why and can anyone think of a way of finding out where and solving this?
Zsh has multiple init files that are sourced. The file .zshenv is always sourced, when the shell starts and the file .zshrc is only sourced when the shell is started in interactive mode.
If you define the variable ARDMK_DIR with different values in .zshenv and in .zshrc, the value from .zshrc will be used when you work interactive with the shell (entering commands, starting Vim, ...).
But when Vim starts a command it will start a non-interactive shell. In that case only the file .zshenv will be sourced, so you get the value from that file.
One question left:
Why did the following command first echo the correct value, but make uses the wrong?
:setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\
For testing, I started Vim under strace. Then :
:set makeprg=echo\ $EDITOR
:make
In the strace file I found the following line:
execve("/usr/bin/zsh", ["/usr/bin/zsh", "-c", "echo vi 2>&1| tee /tmp/vdxR5DH/"...], [/* 86 vars */]) = 0
As you can see, Vim executes echo vi, so it already expanded the environment variable $EDITOR to its value before calling the shell.
So the answer to the above question is, that the echo command echos the text, that Vim inserted into the command line while the make command gets the the variable value from the environment. As it is a non-interactive shell, it is the value from .zshenv.
I have added HADOOP_INSTALL and it's bin to the PATH variable in my .bash_profile (shown below) and executed it using the command . .bash_profile. I can run the command hadoop version fine but when I close the terminal and run the same command again it gives me error as follows
gsidevas#gsidev-cloudvm ~]$ hadoop version
bash: hadoop: command not found
Current .bash_profile
export HADOOP_INSTALL=/usr/local/hadoop
PATH=$PATH:$HOME/bin:$HADOOP_INSTALL/bin
export PATH
What do I need to do so that this HADOOP_INSTALL and it's bin gets set permanently in my environment?
By default, BASH reads and executes commands in .bash_profile only in login shells. If you're creating a terminal via some X11 or similar software, chances are that terminal is not a login shell by default.
You can achieve this effect for every shell by simply moving the changes you made into your .bashrc file. Please note that this only works properly if your username on the system uses "bash" as its shell and not "sh" since for "sh" the .bashrc file is, by default, ignored.
I am having a shell script ./my_shellscript.sh, its contents are as follows :
source /path/to/shell_script.sh
Where shell_script.sh contains:
export PATH=/path/to/a/dir:$PATH
which command_name
when I execute the my_shellscript.sh then it shows accurate path to a command, that I executed using "which" command?
When the shell_script.sh terminates and when I again do "which command_name" from command line it doesn't shows any path as it shown when I executed the scripts.
My question is that how to set/persist that path to environment variable [PATH:$PATH] though shell_script.sh terminates?
That's not how environments work, you can't change the parent environment. You can only change your environment, and (optionally) that of child processes to your process.
You could run your ./my_shellscript.sh with source (or .) to export it's variables to your current environment.
source my_shellscript.sh
or
. my_shellscript.sh
Other option to put the PATH variable extension into your .profile file in your home directory. (/home/your_username/.profile) That will be permanent.
I have a few questions on this $PATH in Linux.
I know it tells the shell which directories to search for executable files, so:
What does it mean an environmental variable?
How to change its path? and is it recommended to change it?
IF i change it what are the consequences?
To get your path current $PATH variable type in:
echo $PATH
It tells your shell where to look for binaries.
Yes, you can change it - for example add to the $PATH folder with your custom scripts.
So: if your scripts are in /usr/local/myscripts to execute them you will have to type in a full path to the script: /usr/local/myscripts/myscript.sh
After changing your $PATH variable you can just type in myscript.sh to execute script.
Here is an example of $PATH from RHEL:
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/user/bin
To change your $PATH you have to either edit ~/.profile (or ~/.bash_profile) for user or global $PATH setting in /etc/profile.
One of the consequences of having inaccurate $PATH variables is that shell will not be able to find and execute programs without a full $PATH.
Firstly, you are correct in your statement of what $PATH does. If you were to break it somehow (as per your third point), you will have to manually type in /usr/bin/xyz if you want to run a program in /usr/bin from the terminal. Depending on how individual programs work, this might break some programs that invoke other ones, as they will expect to just be able to run ls or something.
So if you were to play around with $PATH, I would suggest saving it somewhere first. Use the command line instruction
echo $PATH > someRandomFile.txt
to save it in someRandomFile.txt
You can change $PATH using the export command. So
export PATH=someNewPath
HOWEVER, this will completely replace $PATH with someNewPath. Since items in path are separated by a ":", you can add items to it (best not to remove, see above) by executing
export PATH=$PATH:newPath
The fact that it is an environmental variable means that programs can find out its value, ie it is something that is set about the environment that the program is running in. Other environmental variables include things like the current directory and the address of the current proxy.
this is simple and i do like this way.
Open the linux bash shell and print the environment variables:
printenv
I copy "PATH" variable to a text editor and edit as I want. Then update the PATH like this
export PATH= /variable dir list/
It Works.
or if you want to add an single variable use this command.
export PATH = $PATH:/variable_dir_path/
This will extends the PATH with your new directory path.
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.