When using bash, if I have an environment variable called SOMEPATH which contains a path (e.g. SOMEPATH=/usr/local/lib), then if I type
ls $SOMEPATH/
and hit tab then bash expands the environment variable so my command line now says
ls /usr/local/lib/
If I do the same thing in zsh it instead escapes the $ sign so after tab completion the command line looks like
ls \$SOMEPATH
How can I get zsh to behave like bash does in this regard?
I've done a lot of googling but I haven't managed to find anything that exactly addresses this issue. I've also tried reading the zsh documentation but again I couldn't find anything that obviously relates to this.
Thanks for any pointers.
Related
When I try to run a shell command in ipython or the julia repl it just says
shell> ls
zsh:1: command not found: ls
Not sure if it matters, but I have my path set in zshenv instead of zshrc so that emacs shell works.
Any ideas?
Edit:
I'm on macOS 10.14.6
For Julia, The shell> REPL prompt does in fact use a shell to execute its commands (on non-Windows systems). It effectively does something like run(`$shell -c ls`), and for most shells (including zsh) this means "non-interactive" mode and limits the number of init files that get loaded. You want to make sure your shell is working in this mode; I'd guess that if you type zsh -c ls at your terminal it'll be similarly broken.
Alternatively, you can customize which shell Julia uses through an environment variable. Setting JULIA_SHELL=/bin/sh is probably a safe bet — Julia uses that environment variable if it is set, otherwise it uses SHELL, and finally it falls back to /bin/sh if neither is set.
I'm not as familiar with ipython, but I'd wager it's doing something similar.
after the installation following the instructions with
curl https://nixos.org/nix/install | sh
and logout/login, nix-env and nix-build are not found.
I had the problem with debian stretch and now with buster. What am I doing wrong?
The nix manual instructs to execute
source ~/.nix-profile/etc/profile.d/nix.sh
but the instructions printed after the execution say to do (I do not remember exactly)
./~/.nix-profile/etc/profile.d/nix.sh
and the same command is inserted into ~/.profile. The cause of the problem is the difference between . and source (see this superuser question). The script is setting up the $PATH variable in the environment and has the desired effect wtih source but no effect with . (which operates in its own shell and closes it at the end).
Cure:
change the line in .profile (or better move it to .bashrc) to
if [ -e /home/xxx/.nix-profile/etc/profile.d/nix.sh ]; then source /home/xxx/.nix-profile/etc/profile.d/nix.sh; fi
(xxx is your user name),
You need to add this recommended script.
For me only setting $PATH like this worked (in .profile)
export PATH="$PATH:/nix/var/nix/profiles/default/bin"
when checking my $PATH on ubuntu (16.04)
I get a long list of directories, few of which even do not exist in my file
system, and some of them I just don't need:
echo $PATH
.../usr/games:/usr/local/games:/snap/bin
where they are created and how can I remove them?
I wnant to control the creation of the $PATH, rather than
correct it later by the tricks described in
https://unix.stackexchange.com/questions/108873/removing-a-directory-from-path
Some typical places where $PATH can be set when starting up a bash shell on Ubuntu include:
/etc/profile
~/.profile
~/.bashrc
where ~ represents your home directory.
Also look at any scripts called by those scripts.
There may be other things that get called when starting up a bash shell, depending on various conditions. For details, take a look at the INVOCATION section from the command:
$ man bash
See this answer from askubuntu.com to edit the path either using a text editor or the command line.
I found the answer to your question today. The path you want to edit is in /etc/environment.
when I try to use fabric to deploy Apache server remotely using Fabric, I encountered a problem. I tried to add a new path to the PATH variable first using sudo(), then I tried to echo $PATH using sudo() too. However, I found that it looks like the new path wasn't added to PATH at all. As a result, I cannot execute the bins in that path via sudo().
[name#IP:port] Executing task 'reboot'
[name#IP:port] sudo: export PATH=$PATH:/new/path/to/add/install/bin
[name#IP:port] out: sudo password:
[name#IP:port] sudo: echo $PATH
[name#IP:port] out: sudo password:
[name#IP:port] out: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Could anyone tell me how to add a path variable to sudo command in Fabric? Thanks in advance.
It should be habit to always give a full path to the executable when running as root, to avoid having trojan horses being pushed into your PATH.
Setting an environment variable via export works only for the current shell session - which is the one invoked by sudo. Once your command (export, in this case) is executed, the shell exits, and takes your environment variable with it. The next time you execute sudo, a new shell (with default environment) is set up, which does know nothing about your previous export.
The configuration file /etc/sudoers usually contains an entry like Defaults env_reset, the effect of which is that environment variables set in the calling environment are not copied to the environment invoked by sudo, so calling export in your current environment and then executing sudo does not work either. This is done for security reasons (ref. 1) above).
It is possible to set up /etc/sudoers to make exceptions to 3), via env_keep. Refer to man sudoers for details. However, see 1) - it is not a good idea.
There is the -E option to sudo, which allows to keep the caller's environment (including e.g. an extended PATH), but this requires SETENV being set in /etc/sudoers. Again, refer to man sudoers for details, and be mindful of 1).
use
sudo('PATH=$PATH:/new/path/to/add/install/bin commad')
I was trying to set up a bash command in Terminal on a Mac.
The scripts run correctly when I execute them directly.
I set up symlinks in /usr/local/bin/ to the current location of the scripts. When I try to run it off the symlink, it doesn't work. I don't believe the issue is the $PATH, because pip, git, ipython all exist in this location. When I edit the $PATH setting, these fail.
Suggestions?
ls -l /usr/local/bin/foo and see where your symlink is actually pointing. Betcha it's broken.
If not, try running /usr/local/bin/foo. If that works, it was your PATH that's wrong, despite what you said in the OP.
The only other thing that would cause this behavior is if the script is reading $0 (its own name as executed). With a symlink, that will have a different value.
I found my own answer... The symlinks were created by an automated file which was gabbing my pwd. I was also using virtualenv, so to get it to work, I had to activate the virtualenv and be inside the folder that had the script that created the symlinks.
I install my commands in $HOME/bin instead of /usr/local/bin, but it does not matter much. As hinted in the comments, one question is whether the symlinks are set correctly.
Check which command the shell thinks you should execute: which command
Check that the link in /usr/local/bin points to the correct file (and has execute permission, etc):
ls -l /usr/local/bin/command
ls -lL /usr/local/bin/command
Check that the interpreter path in the shebang is correct:
file /usr/local/bin/command
Check that /usr/local/bin is actually on your PATH: echo $PATH
If none of that shows up a problem, show us the results of the commands above.