When I'm activating python virtual environment, fish always prints venv name in brackets before my fish promt.
antonio:~/W/s/src >
antonio:~/W/s/src > source ../env/bin/activate.fish
(env) antonio:~/W/s/src >
I want to avoid this (env) thing and handle virtual envs by my custom fish_prompt function.
it's doesn't matter, what code I have in ~/.config/fish/functions/fish_prompt.fish - fish always prints (env) and only after that executes my fish_prompt.fish function
The (env) is not prepended by fish. It is done by the virtualenv itself.
You may disable the behavior by exporting VIRTUAL_ENV_DISABLE_PROMPT=1. See this answer about setting virtualenv prompt.
Related
In my fish shell script 'hoge.fish`, I have a code to set envs.
#!/usr/local/bin/fish
set -x HOGE "hello"
but after I exec this script the env is not set correctly and outputs nothing.
./hoge.fish
echo $HOGE
I've tried these code but none of these worked.
set -gx HOGE "hello"
set -gU HOGE "hello"
how can I fix this?
OS: macOS High Sierra 10.13.6
fish version: 2.7.1
iTerm2: 3.2.0
When you ran the script, it probably set the environment variable correctly, but only in the process that was created when you ran the script....not in the parent session you ran the script from! When the script exited, the process and its environment were destroyed.
If you want to change the environment variable in your current environment, depending on what interactive shell you're using, you can use a command like source hoge.fish, which will execute the commands in your current session rather than a subprocess, so the environment variable changes will persist.
While sourceing, as in the original answer is definitely the correct mechanism, a comment from the OP to that answer mentioned that they would still prefer a solution that could be executed as a script.
As long as the variables are exported (set -x) in the script, it's possible (but still not necessarily recommended) to do this by execing into another fish shell inside the script:
#!/usr/bin/env fish
set -gx HOGE hello
exec fish
Executing ./hoge.fish will then have a fish shell with HOGE set as expected.
However, be aware:
This will result in two fish shell processes running, one inside the other. The first (parent) is the original fish shell. It will spawn a second (child) process based on the shebang line, which will then be replaced by the third instance from the exec line.
You can reduce the number of shells that are running simultaneously by starting the script with exec ./hoge.fish. That results in the shebang script replacing the parent process, and then being replaced by the exec line at the end of the script. However, you will still have run fish's startup twice to achieve what a simple source would have done with zero additional startups.
It's also important to realize the environment of the new shell will not necessarily be the same as that of the original shell. In particular, local variables from the original shell will not be present in the exec'd shell.
There are use-cases where these pitfalls are worth execing a new shell, but most of the time a simple source will be preferred.
Consider that if you run that from bash shell it will not export the variables with the -U option because it indicates to export to "fish universe" not outside.
If you stay inside fish's shell you still can do it like this:
#!/usr/local/bin/fish
set -Ux HOGE "hello"
And this is the result:
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
~/trash $ ./hoge.fish
~/tr ash $ echo $HOGE
hello
Remember to keep the first line so fish will interpret it properly.
I'm new to the fish shell, and just trying to set my $EDITOR variable so that's it's persistent across sessions and reboots. Here's what I've tried so far:
Running set -gx EDITOR vim from the command line.
Running set -Ux EDITOR vim from the command line.
Running those commands, prefixed by set -e EDITOR to unset any previous value.
Adding the above commands to my ~/.config/fish/config.fish file (it complains set: Warning: universal scope selected, but a global variable “EDITOR” exists.)
Uninstalling oh-my-fish and removing all fish configs to start from scratch.
No matter what I do, the EDITOR variable always ends up being /usr/bin/nano whenever I open a new terminal, start a new session, or reboot. What's even more strange is that in ~/.config/fish/fishd.my-hostname, I see SET_EXPORT EDITOR vim, and nothing about nano. Is this some kind of fish default? If so, how can I set this correctly?
Edit: I'm running Fish 2.6.0 on Antergos Linux.
First, the fish config file is ~/.config/fish/config.fish. Editing the file you named won't have any effect. Second, fish does not have any default for, nor does it set, the EDITOR or VISUAL variables. So whatever is setting it to /usr/bin/nano is a customization unique to your system.
If you set -Ux EDITOR vim and do not set it in config.fish it should be set to vim even if it is already set when fish starts. Run that set command then do set -U | grep EDITOR and env | grep EDITOR to see that it is set as a universal variable and exported. Now type fish to start a sub-shell. Run the previous two commands and you should see that it is still set to the same value. Now type set -U EDITOR nano in the sub-shell followed by exit. In the earlier shell you should now see that EDITOR is set to nano.
Personally I don't like to use uvars for this since at the moment they are per-machine. I just do set -gX EDITOR (type -p vim) in my ~/.config/fish/config.fish. This ensures that if I start fish on a new machine on which I've installed my ~/.config/fish directory I get my expected defaults.
The other reason not to use a uvar in this way is that the resolution order is local scope, global scope, universal scope. Since environment vars imported when fish starts running are placed in the global scope they will shadow the uvar you defined. Do not export universal variables. It is unlikely to produce the desired results. Simply set -gx the var in your config.fish script.
P.S., When asking questions of this nature you should always include pertinent facts such as the OS you're using and the fish version.
My pyenv is working just fine, but it does not seem to be running my activate script located at /usr/local/var/pyenv/versions/project/bin/activate.fish
When activating my environment it gives the following output, but it does not echo anything from the activate script, which indicates that it is not running.
dani#localhost ~/d/project> pyenv activate project
pyenv-virtualenv: prompt changing not working for fish.
Of course I can just source the file manually, but I'm too eager to find out why it is not running. Is there some kind of debug mode? I'm not sure how to approach.
Actually,
Virtual environment is activated but the message just says that your prompt wasn't changed. Updating prompt was intentionally removed from fish shell.
you can find detailed information here;
https://github.com/pyenv/pyenv-virtualenv/issues/153
If you want to see virtual environment is really activated or not,
run the following command;
pyenv which python
it should print something like;
.pyenv/versions/{your-virtual-env}/bin/python
try this:
set PYENV_ROOT $HOME/.pyenv
set -x PATH $PYENV_ROOT/shims $PYENV_ROOT/bin $PATH
pyenv rehash
In bash one can write
CFLAGS="-O2" rvm install 2.0.0
to run rvm with that specific CFLAGS . Is there anyway to do the same in fish shell?
I know about set -x but that is not exactly the same as the environment variable will be set for the whole session instead of just for that command.
According to the fish FAQ, either use:
env CFLAGS="-O2" rvm install 2.0.0
(which will not work for fish builtins or functions, only external commands), or
begin
set -lx CFLAGS="-O2"
rvm install 2.0.0
end
(which is a little clunky; there are proposals for improvement on GitHub issue #438).
You can use the env command for this:
env FOO=BAR command
Will run command with env variable FOO set to BAR.
I'm trying to compile u-boot via Emacs' compilation mode, and it looks like Emacs doesn't know how to find bash environment variables. Even though I set them, and can compile via Emacs shell emulation, compilation mode still tries to compile as if they aren't there.
What do I need to do to make it more environment conscious?
You can try adding something like to your .emacs:
(let ((path (shell-command-to-string ". ~/.bashrc; echo -n $PATH")))
(setenv "PATH" path)
(setq exec-path
(append
(split-string-and-unquote path ":")
exec-path)))
Depending on whether you've set the env variables in .bash_profile or .bashrc you might need to slightly adjust this snippet. The example is for the PATH variable, which is a bit more special (since you have to set exec-path in Emacs as well), but can be extended to work for arbitrary variables - you could have a list of variables that have to be read from .bashrc and set into Emacs.
I'm not sure whether you're using OS X or GNU/Linux. Starting Emacs from the GUI's menu-bar in Linux will typically result in an Emacs that does not have the same PATH as one launched from the command line. This problem dates back to the first xdm Xsession scripts, and while they are fairly easy to fix (basically use an Xsessionwrapper script that does exec $SHELL -c Xsession so the shell gets run before running the user's Xsession), nobody has bother to do so in a very long time (and I doubt that anyone will). As far as I know the problem is present even into moder xdm descendants such as kdm and gdm.
On OS X the handling of the env variables is another problem entirely and to get your ENV variables you typically have to run Emacs from the command line like this /Applications/Emacs.app/Contents/MacOS/Emacs or play with ~/.MacOSX/environment.plist. The code snippet I've provided should cover you in both cases though.
Update
Recently this process was made easier by the exec-path-from-shell extension. It sets the emacs $PATH in more or less the same manner, but using an extension is generally preferable to hacking the solution yourself.
This is where the environment variables of the process that started emacs are:
— Command: getenv var
This function returns the value of the
environment variable var, as a string. var should be a string. If var
is undefined in the environment, getenv returns nil. It returns ‘""’
if var is set but null. Within Emacs, a list of environment variables
and their values is kept in the variable process-environment.
(getenv "USER")
⇒ "lewis"
— Variable: process-environment
This variable is a list of strings,
each describing one environment variable. The functions getenv and
setenv work by means of this variable.
process-environment
⇒ ("PATH=/usr/local/bin:/usr/bin:/bin"
"USER=lewis"
"TERM=xterm"
"SHELL=/bin/bash"
"HOME=/home/lewis"
...)
You seem to be assuming that emacs was started from a bash session. However, often processes under X are started from an sh session, which would not read the environment variables you had set in your ~/.bashrc script. One simple way to circumvent this is to change your ~/.xinitrc file to use bash instead of sh (it could be as simple as adding #!/bin/bash at the top of the file).
Source: gnu.org
It doesn't strictly answer your question, but you can always pass environment variables on the make command-line. For example : M-xcompileRETmake -k CXXFLAGS='-Wall'RET