I've installed emsdk, following the steps described in the following document: https://emscripten.org/docs/getting_started/downloads.html#sdk-download-and-install
Now, when I launch a Terminal under macOS, I have these lines inserted at the beginning:
Setting up EMSDK environment (suppress these messages with EMSDK_QUIET=1)
Adding directories to PATH:
PATH += [private]/emscripten/emsdk
PATH += [private]/emscripten/emsdk/upstream/emscripten
PATH += [private]/emscripten/emsdk/node/14.18.2_64bit/bin
Setting environment variables:
PATH = [private]/emscripten/emsdk:[private]/emscripten/emsdk/upstream/emscripten:[private]/emscripten/emsdk/node/14.18.2_64bit/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Little Snitch.app/Contents/Components:/usr/local/share/dotnet:/opt/X11/bin:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
EMSDK = [private]/emscripten/emsdk
EM_CONFIG = [private]/emscripten/emsdk/.emscripten
EMSDK_NODE = [private]/emscripten/emsdk/node/14.18.2_64bit/bin/node
EMSDK_PYTHON = [private]/emscripten/emsdk/python/3.9.2_64bit/bin/python3
SSL_CERT_FILE = [private]/emscripten/emsdk/python/3.9.2_64bit/lib/python3.9/site-packages/certifi/cacert.pem
I can't find from where this is launched. emsdk doesn't appear in .bash_profile, nor in .profile or .bashrc.
Where do I have to set EMSDK_QUIET=1 to avoid these lines?
A lot of times when you install a program that needs to alter the environment like compiler toolchains the install script will modify the file it expects to be sourced by your shell based on the default shell for the current user or sometimes by scanning $HOME. On MacOS you might see it add a line to (or create if it can't find):
$HOME/.bashrc or $HOME/.bash_profile for bash
$HOME/.zshrc or $HOME/.zprofile for zsh
$HOME/.config/fish/config.fish for fish
Note that recent versions of MacOS have changed the default shell from bash to zsh. Due to licensing issues they have to ship an archaic version of bash (3.2 vs 5.x current) so it was probably a good move but it means you may need to check the zsh files instead of the usual bash ones.
When you need to set an envar for a toolchain like EMSDK_QUIET=1 just look for the line where the environment is sourced, and export that envar above it.
Related
I am studying zsh on macOS and I find when adding software to $PATH you are usually supposed to write them in .zshrc (zsh). However, Visual Studio Code documentation suggests
To add VS Code to your path, to do so run the following commands:
cat << EOF >> ~/.zprofile
# Add Visual Studio Code (code)
export PATH="\$PATH:/Applications/Visual Studio Code.app/Contents/Resources/app/bin"
EOF
I find zprofile set the environment for login shells while zshrc sets the environment for interactive shells. However, I cannot really see differences between two methods on macOS terminal since each terminal tab is a login session on macOS by default.
Is there any reason why Visual Studio Code on macOS suggests add $PATH to zprofile instead of zshrc and what will be the good practice?
If you read this and this answer as well as the man page (man zsh under STARTUP/SHUTDOWN FILES) you might come to the following conclusion:
You are using MacOS, therefore every zsh you open is a login shell, that way you made sure, that .zprofile will always be read. So if you append your $PATH in your .zprofile and and use zsh as a non interactive-shell you will be able to access your appended $PATH. This might happen in a script of if other programs try to use a program that you added to your $PATH.
Now on the other hand if you added VSCode to your .zshrc it will always be available in an interactive shell. Which mean if you use VSCode 'manually' you will always have it at your disposal in zsh. But other programs/scripts might not find it.
If you set environment variables in .zshrc or .zshenv it can be awkward if you want to use a different value. Say you install a different version of vscode in a different directory. Any new shell will reset the environment variable instead of inheriting it. As environment variables are inherited, there is no need to reset them for every new shell. So .zprofile is often a better choice - the variable is set on first login and inherited but can be changed for a shell and its children. Another option is to set them from .zshenv but use a condition around them such as if [[ ! -o privileged && -o rcs && $SHLVL = 1 ]]; then
How do some programs seem to add to the $PATH variable without using a .bash_profile file? What are the advantages to these approaches of adding to $PATH variable, but not using a .bash_profile file?
For my mac
echo $PATH returns
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin
which java returns
/usr/bin/java
which tex returns
/Library/TeX/texbin/tex
How is Java available in the terminal without being in the $PATH variable? (This is an example of something running in the terminal without being in the $PATH variable.)
How did TeX add to the PATH variable without using a .bash_profile file?
What added Library/Apple/usr/bin to the PATH variable? Wikipedia says that only the first three are defaults: /bin, /usr/bin, and /usr/local/bin.
Note: Other StackOverflow posts helped users create a .bash_profile file (a file that doesn't exist by default on a Mac) to run programs such as android and adb when they received -bash: android: command not found
My question is about how the terminal works (like how java is running without being on $PATH) and how other programs (like TeX) added to $PATH without using a file like .bash_profile.
I am running macOS 10.15.5, confirmed that I do not have a .bash_profile file, do have homebrew installed (not sure if that affects anything) and when I open a terminal, it says "The default interactive shell is now zsh." (I think I installed zsh after reading a different StackOverflow a few weeks back.
I am trying to fix the bash profile but it constantly says:
source ~/.bash_profile
/Users/KirSo/.bash_profile:160: command not found: bind
\[\e]2;\u#\h\a[\[\e[37;44;1m\]\t\[\e[0m\]]\[\033[0;31m\] (master) \[\e[32m\]\W\[\e[0m\]\n\[\e[0;31m\]\[\e[0;49;34m\]//\[\033[0;31m\] ♥ \[\e[0m\]
checked the line 160 which says:
bind "set completion-ignore-case on"
Although with adjust the line, restarting the terminal it still drops the same error.
Considering the path inside the question, You are probably running CygWin or something similar. Check the $PATH variable and Your env variables. You might have accidently changed the paths in which bash is looking for binaries (such as /bin). Also, on some versions of Linux (dont know about CygWin, sorry :<), there are other bash config files, namely ~/.bashrc /etc/bash.bashrc /etc/profile. The names may vary, depending on the distribution and implementation. Check If those contain code that overrides Your $PATH variable.
What is the proper way to modify environment variables like PATH in Yosemite?
This is this question Setting environment variables in OS X? but specifically for yosemite since it doesn't work anymore.
Have you tried editing ~/.bash_profile?
Adding a line like this to bash_profile ought to do it:
export PATH=/usr/local/bin:$PATH
What shell are you using? I'm assuming you're using the default Bash shell. There's also Csh, Ksh, and Zsh.
The Terminal.app on Mac OS X by default starts a new login shell each time a window is open. This means that $HOME/.bash_profile or $HOME/profile is always executed when you open a new terminal window. You can set particular defaults in here. For example, I set PS1 and set -o vi.
NOTE: This may not be the case if you're using other Terminal apps like xterm. These open new terminal windows as just new shells. This means that you may not see the changes made in .bash_profile until you log out and log back in.
You can try editing $HOME/.bashrc and see if that helps.
What about other shells?
If you're using Kornshell (ksh), you need to edit the $HOME/profile and not $HOME/.bash_profile. If you're using Zshell (zsh), you're on your own. It's too wacky to describe here. Read the manpage for zsh and search for ZDOTDIR.
When you run a shell script, the $HOME/.bashrc is executed. Most people put something like this in their .bash_profile, so their .bashrc settings are included in a new terminal window:
[[ -x $HOME/.bashrc ]] && source "$HOME/.bashrc"
Some people set things they want to be set when they run a shell script, for example export $PS4="\$LINENO> ".
The $PATH is a bit different. You can set it in .bash_profile (I would not set it in .bashrc), But, Mac OS X has an automated why on how systemwide paths are set. A file called /etc/paths is used to set the default path for all users using either Bash or Kornshell via the /usr/libexec/path_helper program.
On my Mac, I set my $PATH to:
/usr/local/bin:/usr/share/bin:/bin:/usr/bin:/usr/sbin:/sbin:$HOME/bin
When I install programs, I usually install them under /opt when possible. Then, I link their binaries (where ever they're placed) to /usr/local/bin. This way, I don't have to keep building my PATH. Plus, it allows me to override system defaults. For example, /usr/bin/git is at 1.9.3. while my installed /usr/local/bin/git is at version 2.2.1.
One thing you should not do is modify /etc/profile because changes there may be replaced on OS X upgrades.
The problem is not with environment variables set and accessed from within /bin/bash or /bin/sh, but with envars that should be set for programs NOT executed from the shell; i.e. normal apps executed from the dock or Finder.
After finally getting things right with launchctl in Mavericks, Apple is in the process of changing things again. The useful subcommands of launchctl are now labelled as "legacy subcommands", some of which are no longer supported. That leaves a question mark over the others.
In any case, the most important subcommands are still available for now.
launchctl allows for the setting of the overall environment in which user processes execute. It appears that the overall user environment is inherited by all Terminal processes; i.e. all setenv variables are exported. It's a bit tricky to confirm that. In any case, you will still need your .profile and .bashrc to define functions and aliases, which are not supported by launchctl.
I go to some lengths to ensure that all of my launchctl vars are also defined in my profile. This enables me to set up the same environment on remote or VM linux systems, with a few minor tweaks.
Al of my setup is described in this blog post .
following solution worked for me.
Open Terminal
Click on Terminal Menu at right upper corner.
click on Preferences
Click on General
Change Shell open with to command and put /bin/bash in text box.
Now whatever configuration you do in ~/.bash_profile takes effect. Previously you were not using bash(were using ksh) that is why it was not reading .bash_profile.
I'm using ant to build my project, and use the 'svnversion' executable to insert a version id into my sources for easy tracking of versions.
Running this ant file from the command line works, I've set my $PATH in .profile to include the path to svnversion and it works fine.
Now I try and run this same ant file from inside Eclipse and that does not work - the PATH in eclipse is set in another way than the PATH of the shell, I suspect this has to be set in a plist somewhere, but I don't know where.
Correct -- it's in the plist file
~/.MacOSX/environment.plist
This file actually contains key-value pairs for any environment variables you want to set, for the whole login session. Unlike .profile/.cshrc etc, it's available to GUI programs. Unfortunately, you can't access other environment variables (e.g., you can't use $HOME) or use any other programmatic constructs here.
Update: note that this is no longer supported under OS X 10.8 Mountain Lion, alas.
A quick search at developer.apple.com turned up Setting environment variables for user processes.
On Mac OS X El Capitan (10.11.5), this works for me for per-user PATH entries (and other environment variables, for that matter).
create a file $HOME/.profile
set all PATH related variables in that file
(if using bash), have your .bash_profile source that file, and .bashrc. This should be the entire contents of your .bash_profile:
# $HOME.bash_profile:
source $HOME/.profile
source $HOME/.bashrc
Near as I can tell, Mac OS does not source .bash_profile on login for PATH, presumably because that is often very slow to run (initializing bash completion etc). It does seem to read $HOME/.profile.
You still need a $HOME/.bash_profile to trigger bash to read $HOME/.bashrc, which it otherwise wouldn't do for interactive, non-login terminals as the ones created by Terminal.app.