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.
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 am not sure this is clear to me and if is neat for my system. I'm aware of the ~/.zhrc file where I can store alias and paths, but today after installing node via brew I was asked to put this: export PATH="$HOME/.npm-packages/bin:$PATH" in my ~/.bash_profile file, which it doesn't exist, thus in my effort to keep my system clean I putted it in the former file but emacs complaint. Now, I removed it and putted it, after creating, in the ~/.bash_profile. Is that OK to keep both in the home directory?
You need to provide the exact wording of whatever error or warning message you
get from emacs to ensure accurate or better answers. However, I will make a
guess and assume the warning you are getting is from the exec-path package.
This package has a check, which you can disable, that looks to make sure you
have variables defined in the correct init file.
In general, most shells support two types of configuration files
Startup or Login init files
Interactive shell init files
The difference is how often or when the files are sourced (loaded). To
understand the difference, you really need to understand when a shell is run and
the relationship between each shell. I'll try to give a vary high level
explanation, but you really should read the manual page for the particular shell
you are using.
Think of your environment as a tree of shell processes. When you login to the
system, a login shell is created. This shell will be the parent of all the other
shells you create. Each time you run a command, it is executed in a new shell
(this isn't 100% accurate, but is accurate enough to explain the main
points). So when you open a terminal, it runs another shell which is a child of
your login shell. When you execute various commands, the system creates a new
shell and runs that command inside the shell. These are all children of your
parent login shell. Some shells only exist for a short period of time (as long
as it takes to execute the command), others may last for hours, days or possibly
weeks (such as the shell that emacs is running in).
The important point to keep in mind is that child shells inherit various
settings from the parent shell. The idea of the 'export' command you will see in
front of some variables is actually a command to the shell telling it to export
the variable to child shells. For example, if we have a line like
export PATH=/usr/local/bin:/usr/bin:/bin
what we are really doing is
PATH=/usr/local/bin:/usr/bin:/bin # set the variable
export PATH # make it available in child shells
We don't always want variables to be exported as some variables need to be reset
in the child shell itself. For example, the variable holding the prompt string.
It would not work to have this variable only defined in the login parent shell
if you want the prompt to have dynamic components, such as the current
directory, date or time. We want these types of variables to be defined in each
shell when it is created.
To handle this, shells have the two different init files. The login init files
are only sourced for the parent shell and are particularly useful for setting
variables that will be common to all child shells. the per-shell init files are
sourced for every new shell and are best used for setting things which need to
be updated or changed each time a shell is started. There are also other shell
configuration files which can be used for other special purposes, such as when
you log out or log off a system, or to just put alias definitions in etc.
Once upon a time, it made a big difference where you put your variables as there
was a performance hit when sourcing these init files. If the per-shell init file
was too large and consumed too many resources, the whole performance of your
environment could be affected. This is largely less of an issue these days due
to increased processing speeds. Unfortunately, because many people didn't
understand the role and relationships between the different shell configuration
files, there is lots of incorrect or misleading information out there regarding
where values should be set. People often advise setting variables in (for
example) bashrc when they should be set in the bash__profile=. The confusion is
partly caused by the fact you can add a variable to bashrc and it will work when
you test it (usually because your test involves forking a new child shell) and
putting it in your bash_profile will only work after the next login.
There are also some platform differences which make things a little less
clear. For example, under OSX, there is actually a special file in the /etc
directory where you should add additional path components (I'm not on a mac just
now, but it is something like /etc/paths or a per path component file in
/etc/path.d). This is done so that you have a global place to set paths which
will ensure desktop processes, such as the dock, which do not run as a child
process of your login shell, are able to be set.
As a general rule, most variables can go in the login profile, with the
exception of variables relating to the prompt or other variables which have a
dynamic content i.e. content which changes depending on time, directory
location or other tracking of interactive actions which are specific to a shell
instance.
Setting of the path (noting OS differences as described above) should go into
the profile or login configuration file. Under bash, this is .bash_profile and
under zsh, it is typically .zprofile. As bash has become the most common shell,
documentation etc often advises adding things to .bash_profile. If your running
zsh, then add the same information using .zprofile.
As you have said you don't have a.bash_profile, but you do have a zshrc file, I
am assuming you are running zsh rather than bash as your login shell. This being
the case, you need to add that path setting to .zprofile in your home
directory. The exec-path package is complaining because you added it to
zshrc/bashrc, which are not the correct place to set path variables. If your
running under OSX, you really need to add the path to the correct file in /etc
(you will need to check the OSX documentation as I cannot remember the precise
filename).
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
I changed the environmental variable LD_LIBRARY_PATH from the Ubuntu terminal (because I was receiving an error) and the changes were applied when I ran code (a Python code) from the terminal. But when I ran the same script from the Visual Studio Code, the error remains. How to update the environmental variable so that Visual Studio Code sees it, as well?
Environment variables are passed from parent process to child process; they are not (say) global to the system or the user. If you change a variable in one shell, the change is only seen in that shell and any processes started from that shell. So the simplest solution is to change the variable and then start VSCode from that same shell:
$ export LD_LIBRARY_PATH=/some/useful/path
$ code
If you want to keep using that shell for other things, run it in the background:
$ code >/dev/null 2>&1 &
The redirection to /dev/null is needed because otherwise VSCode prints logging information periodically, and that output will be mixed with whatever else you're doing.
If you want to set the variable permanently, see the question How do I set a user environment variable? (permanently, not session). After following those instructions, you'll need to start a new shell (and possibly even logout and login) first so the settings take effect. Then launch VSCode from the new shell.
I am using a vpn service from certain server. I was given with a root account, and when I connect with a root account, the command line looks like below.
root#xa9g82:/etc/#
Then I used useradd to add an account called 'temp'
When I connected to the server with temp, then the command line only has a single character.
$
The user information is not shown, neither the path. Also, note that, in root's command line I can use tab to automatically complete the filename, however 'temp's command line inserts tab space, when I press tab. It is very inconvenient.
I am using Ubuntu 10.04. How can I resolve this issue?
I usually edit ~/.bashrc. Being root, you might want to change the system-wide preferences, at /etc/bash.bashrc. Personally, I changed some lines in ~/.bashrc to look like:-
# If this is an xterm set the title to user#host:dir
case "$TERM" in
xterm*|rxvt*)
## PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u#\h: \w\a\]$PS1" # default
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\h: \W\a\]$PS1" # How I like it
;;
*)
;;
esac
use prompt to set the prompt.... (man prompt...)
it depends on what shell you run each one has it's own tricks, but you can make it looks as you wish.
BASH
TCSH
It is likely that the default shell for root is set to /bin/sh, which does not provide many of the features that you may used to if you use a shell like bash. To check if this is the case, run the following command:
cat /etc/passwd | grep ^root
The last component of the line that this command outputs will be your shell (which, as stated previously, I'm guessing is /bin/sh). If this is not the shell you want (it probably isn't), then edit /etc/passwd (using nano or whatever editor you're most comfortable with) and change your shell to something more palatable, like /bin/bash. After doing this, you'll need to log out and then log back in.