I am doing deploys from specific machines. These are the same machines
being used for development. This situation can cause some problems
since the environment variables desired for deploys can be different
from the ones to be used for development!
When the engineer is developing, it is useful to have a .zshrc file with stuff like:
export TFR_RELEASE="my-instance-for-development"
export TFR_DEV="my-instance-for-development"
However, the instance for the deployment is a different one!
The project already has a makefile to help streamline things. One of
the make commands is make prepare:
prepare:
lein firebase-all $(instance-variables)
firebase use "$(firebase-name-prefix)$(TFR_RELEASE)"
In order to nudge the developer in a good way, I decided to add the first two lines (and comment out the last 2, just for this Stack Overflow question) on make prepare. This is supposed to be a "short cut" command preparing the environment for the deployment:
prepare:
export TFR_DEV=""
export TFR_RELEASE=""
#lein firebase-all $(instance-variables)
#firebase use "$(firebase-name-prefix)$(TFR_RELEASE)"
So, before executing make prepare I have:
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ echo $TFR_RELEASE
"my-instance-for-development"
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ echo $TFR_DEV
"my-instance-for-development"
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ make clean
rm -rf .shadow-cljs
rm -rf node_modules
rm -rf target
rm -rf public/js
echo "TFR_DEV" "my-instance-for-development"
TFR_DEV my-instance-for-development
echo "TFR_RELEASE" "my-instance-for-development"
TFR_RELEASE my-instance-for-development
The result above is expected considering my .zshrc file configuration.
Unfortunately, after executing make prepare things do not work as expected for me:
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ make prepare
export TFR_DEV=""
export TFR_RELEASE=""
# lein firebase-all
# firebase use "my-instance-for-development"
I was expecting to echo the environment variables and receive an empty value, but the old value remains!
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ echo $TFR_DEV
"my-instance-for-development"
~/projects/balance on 1524-extend-make-clean-to-erase-TFR-environment-variables
➜ echo $TFR_RELEASE
"my-instance-for-development
I suppose .zshrc is not properly harmonized with the makefile.
Is there a way to configure things so that the makefile overwrites .zshrc configuration?
Related
I am trying to install package using go with below command:
go install fyne.io/fyne/v2/cmd/fyne#latest
This is the same as what the instruction said but ideally it should return below message
Users/name/go/bin/fyne
But when I enter the command it has below issue
fyne not found
The package author told me You likely don’t have the GOBIN path added to your PATH variable. I suspect it is golang/go#39531 that comes back to bite you.
When I execute export in the command line:
export
I am getting the below Golang path:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin
I thought the path above was messed up because I have done multiple times of installing and uninstalling with uninstalling using below commands
I've done uninstall via:
$ sudo rm -rf /usr/local/go
$ sudo rm /etc/paths.d/go
Althought I've tried to change via:
vim ~/.zshrc
Add a line
export PATH=$PATH:$(go env GOPATH)/bin
It's still not working.
What’s the best approach to resolve adding GOBIN to path?
Thanks!
If all you need is to add GOBIN to PATH, do:
PATH=$PATH:$(go env GOBIN)
Since GOBIN often is ~/go/bin, you usually could get away with just:
PATH=$PATH:~/go/bin
You can add that command to ~/.zshrc to make it persistent and then source it to execute it immediately:
source ~/.zshrc
After that, if your shell remains unable to find fyne, check that current PATH content includes GOBIN with:
echo $PATH
If it doesn't, something went wrong when adding GOBIN to PATH.
When zsh was exporting a PATH from a script, it didn't read the path correctly.
My PATH was export PATH="~/path/to/stuff/", but when I tried to run a command located at that path, zsh could not find it.
When I changed the PATH to export PATH="$HOME/path/to/stuff/", then the zsh was able to run the command.
EDIT: The strange thing is that I just checked this and it's working again with export PATH="~/path/to/stuff/". There must be something weird going on with my dev environment.
EDIT 2: I failed to mention earlier that the script I am reading export PATH="~/path/to/stuff/" from is building a local dev environment for a team of developers who mainly use bash as their shell. I prefer to use zsh so I have to get my shell to play nice with all of the configs for the dominant bash setup across the team.
Use the following code to get what you want:
export PATH=~/Desktop/Capture/
echo $PATH
# Result: /Users/swift/Desktop/Capture/
Although, when you're using a string, you'll get this:
export PATH="~/Desktop/Capture/"
echo $PATH
# Result: ~/Desktop/Capture/
So to get it right, you'll have to try this approach:
tilde=~
export PATH="${tilde}/Desktop/Capture/"
echo $PATH
# Result: /Users/swift/Desktop/Capture/
P.S. Also, there's one useful command for tilde to be expanded.
Here's an example:
echo tilda=~
# Result: tilda=~
Use magicequalsubst command in zsh:
set -o magicequalsubst
echo tilda=~
# Result: tilda=/Users/swift
I'm currently trying to install MAGMA, however trying to run "sudo make install" gives me the error:
$ sudo make install prefix=/usr/local/magma
make.check-cuda:7: *** Set $CUDADIR, preferably in your environment, e.g.,
run "export CUDADIR=/usr/local/cuda" in ~/.bashrc, or "setenv CUDADIR
/usr/local/cuda" in ~/.cshrc. Stop.
I know for sure that CUDADIR is set, and it's set in ~/.bash_profile, so I'm not sure why it's failing. Is there any reason why it might not being finding it? It seemed to work fine when I ran "make".
$ set | grep CUDADIR
CUDADIR=/usr/local/cuda
It needs to be both set and exported. By looking at the output of set you're just seeing variables which are set in the shell... the shell will only send exported variables to programs (like make) that it invokes. You didn't show us how the variable is set in ~/.bashrc but I assume it's something like this:
CUDADIR=/usr/local/cuda
Change that to:
export CUDADIR=/usr/local/cuda
If you want to see what variables are exported the simplest thing to do is use env, not set, like this:
$ env | grep CUDADIR
I have installed a program that did not automatically put its binaries into usr/local/bin for me. This means that "command not found" errors happen very often whenever I run scripts in that program. I can fix this by copy-pasting the binaries into the usr/local/bin directory, but I don't want to do this every single time, for every single binary. What would be a more efficient way to make the scripts work?
Thank you very much in advance!
Executables are simply resolved via the $PATH variable. It's set to something like
PATH="/bin:/usr/local/bin:..."
(Try $ echo $PATH.)
When you enter a command:
$ foo
each path will be tried in turn and the first matching executable will be executed.
/bin/foo
/usr/local/bin/foo
To execute something outside the default path, simply enter the whole path to the executable:
$ /home/me/bin/foo
$ cd /home/me/bin
$ ./foo
If you find that you need to do that often and want the shortcut, alter your path:
export PATH="$PATH:/home/me/bin"
(Put this in your shell startup script like ~/.profile to automate that.)
Alternatively, symlink the executable to somewhere in your path:
$ ln -s /home/me/bin/foo /usr/local/bin/foo
Add the directory containing the binary to your $PATH environment variable by editing ~/.bash_profile:
export PATH=$PATH:/your/new/path
You can also edit /etc/paths or add a file to /etc/paths.d, but you need to have admin privilege to do that.
For an iPad application I need to transform some CoffeeScript files into JavaScript files before bundling them with the application.
I tried to add a Makefile to my XCode project with the following code:
MANUAL_ROOT=IOS12BSH/manual
SCRIPTS_ROOT=$(MANUAL_ROOT)/scripts
COFFEE_SOURCES=$(SCRIPTS_ROOT)/*.coffee $(SCRIPTS_ROOT)/guides/*.coffee
JAVASCRIPT_TARGETS=$(COFFEE_SOURCES:.coffee=.js)
all: build
build: coffeescript
clean: clean_coffeescript
coffeescript: $(JAVASCRIPT_TARGETS)
clean_coffeescript:
rm -f $(JAVASCRIPT_TARGETS)
$(JAVASCRIPT_TARGETS): $(COFFEE_SOURCES)
coffee -c $(COFFEE_SOURCES)
Running this Makefile from the shell works without problems. However, after I added the Makefile as a target in XCode, I ran into problems.
The following error was produced by the Makefile:
coffee -c IOS12BSH/manual/scripts/*.coffee IOS12BSH/manual/scripts/guides/*.coffee
/bin/sh: coffee: command not found
make: *** [IOS12BSH/manual/scripts/*.js] Error 127
Command /Applications/Xcode.app/Contents/Developer/usr/bin/make failed with exit code 2
That is strange, as the coffee command is installed on my machine (it is installed under /opt/local/bin/coffee and /opt/local/bin is added to my $PATH in ~/.profile).
So I added an echo $(PATH) to my Makefile and it seems that the $PATH is different, when the Makefile is executed by XCode. XCode does not seem to read the settings from ~/.profile and therefore /opt/local/bin is not in $PATH.
What is the reason for this and how can I fix this, so that the coffee command is found?
Well, it seems that programs started via the Dock or Spotlight do not execute .profile and therefore $PATH is not set correctly.
So one way would be to set the $PATH in ~/.MacOSX/environments.plist. That works then apparently, but you will need a restart before it works.
Another way is to start XCode always from the command line with open projectfile.
This answer explains the problem in detail:
https://stackoverflow.com/a/14285335/751061
What ended up working best for me is just to launch Xcode from the command line.
I wrote a simple bash script that looks like:
source ~/.bash_profile # This is the trick that gets us our environment variables.
open -a "Xcode"
And then I call it from an Applescript Application just to give it a bundle I could put on the dock:
do shell script "~/xcode_launcher"
Sourcing your profile is necessary in the bash script, because running a script from Applescript doesn't ever source from a profile, so you still wouldn't have your default environment variables.
SAme thing with ant command. It works on terminal, not if Xcode have to do it. Only way to got it work: sudo open project.xcodeproj in terminal.