So I have a script called kc which compiles Kotlin files into a jar.
The file is located at ~/Documents/KotlinPlayground/bin and my $PATH looks like this:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:~/Documents/KotlinPlayground/bin:~/Library/Android/sdk/platform-tools/
when I just type kc SomeFilt.kt into the command line I get a zsh: command not found: kc, but if I type in ~/Documents/KotlinPlayground/bin/kc SomeFile.kt it works.
So how come zsh can't find my script even though its in the path?
Here is an image showing the problem:
I also tried adding #!/bin/bash to the top of kc and continued getting the same issue
I think the problem is that zsh is not interpreting ~/ correctly. You could replace ~/Documents to /home/user/Documents to solve the problem.
Related
edit : I ended up upgrading to macOS Catalina yesterday and replacing bash with zsh. One thing that should be noted is that the stackcommand worked previously, but despite all the tinkering not ghci
After deleting all the files that had anything to do with Haskell, I retried running curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
This second time there was an error with the command line tools so I had to install them manually with xcode-select --install. After rerunning the curl, I added the path to the environmental file to my zsh profile manually with :
. "$HOME/.ghcup/env"\
echo '. $HOME/.ghcup/env' >> "$HOME/.zshrc"
Here is the content of the env file :export PATH="$HOME/.cabal/bin:/Users/agnel/.ghcup/bin:$PATH"
Now everything seems to be working (I never reinstalled stack, but I think I might leave that to the side while I learn the basics of the language).
I installed the Haskell Platform yesterday but am having a hard time getting it to work correctly.
The firsts steps I did are:
curl -sSL https://get.haskellstack.org/ | sh
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
On step 1. the instructions said to append /Users/.../.local/bin the PATH variable (which I did in /etc/paths. On step 2, the script was supposed to pop up a dialog box (and didn't) when installing the necessary command line tools. It also said to rerun the script once complete (which I did). The script also said I should adjust my PATH variable, and source /Users/.../.ghcup/env in my shell configuration. It asked to this automatically but failed having not found the ~/.bashrc File. (I read that on Mac in contrary to linux, only .bash_profile is loaded upon opening of a terminal window so I adjusted the path variable there manually. I've spent forever messing around with the path variables and every time I try and run "$ ghci" I get the same -bash: ghci: command not found error message. If anyone has a solution to this problem I would be very grateful for an answer. If not, could someone with a working distribution of Haskell on their computer show me what their path variables look like?
Thanks!
A simple solution would just be to restart your terminal and you are good to go.
After installing the Haskell platform for the first time on a new mac with Catalina, I also got
~> ghci
zsh: command not found: ghci
What worked in my case was to use, instead of the plain ghci,
stack ghci
To get back the familiar behaviour, I created in my homedirectory a file named .zshrc containing
alias ghci='stack ghci'
If you open a new terminal, this file will automatically be executed.
I'd be interested to know if there is another solution.
Check if the ghcup command is working or not.
If not, make sure the .zshrc file has command for execution of ghcup. It should look something like this -
[ -f "/Users/myusername/.ghcup/env" ] && source "/Users/myusername/.ghcup/env" # ghcup-env
If the file exists, simply restarting terminal will work.
If it is still not working, set GHC as default using ghcup - follow this
I am trying to refresh my aliases on my Mac (OS Catalina 10.15.6) after defining new aliases in my .bash_profile file with the command:
source ~/.bash_profile
But terminal keeps giving this error message:-bash: s: command not found
This is confusing because for the longest time this command worked. I even had it included in my .bash_profile file as an alias, where it worked fine.
I'm aware the problem could have to do it with an error in my PATH but I've never made any edits to my PATH so have no idea what the issue could be?
Thanks in advance.
My first instinct would be to check both ~/.bashrc, and /etc/bashrc if it exists. That is where I customarily define aliases, and it looks to me as though a bad alias may be your problem.
I'm not saying it was the one you made, although it might be. Just go through your rc and profile files and look for any aliases which might in any way clash with source.
I suspect the source command is working just fine and the problem is a bad line in the ~/.bash_profile itself that looks like it's trying to run a command named s. I would look in there for the problem.
It might help to run it with xtrace on via bash -x ~/.bash_profile – running it in a separate process like that won't have any of the presumably-desired side effects of sourceing it in your current shell, but you can see what it's trying to do so that you can fix it.
(You can also just set -x before the source and get both xtrace and running in the current shell; just be sure to set +x afterwards or your shell session will be full of debug output.)
I'm trying to install a linter for sublime tex in OSX. It cannot be found in sublime. According to the docs, this is likely because the PATH is wrong. It says I should try this:
hash -r
which linter
but replace linter with the "linter executable". I tried
which standard
which sublimeLinter-contrib-standard
which fooBarBaz
but neither of them returns anything. Do I need to execute this in a particluar directory or is something else wrong?
which uses the value of PATH that it inherits. The fact that which returns nothing confirms that you need to add the appropriate directory to your PATH.
which command looks through the directories defined in your shell’s PATH variable, as well as any aliases you have defined in your ~/.bash_profile file, to find the location of the command given as an argument. This is useful when you want to find out exactly which version of a command is being used. Here’s an example:
$ which ls
/bin/ls
This tells you that when you use the ls command, it is /bin/ls that is run. This command will also tell you if a specific command is a shell builtin.
A majority of terminal commands don't work, for example .
ls
sudo
vi
with the error -bash: ls: command not found my path is echo $PATH
“/Users/username/usr/local/bin I get the feeling that “ should not be there but not sure how edit it.
What should the path be and how do I get the path to stay the same?
You need to add more paths to your $PATH variable. Try running whereis ls and check where is the binary of the command.
You can add more paths like this: export PATH=$PATH:NEW_PATH
I had a similar experience recently where a lot of my terminal commands were not being found despite being clearly saved in my bash_profile. After lengthy process of elimination I realised that the issue was caused when I tried to export a new path. The error that I had made was putting a space in the command. So I had to change
export SOMETHING = /path/to/something.apk to
export SOMETHING=/path/to/something.apk
So I would recommend you check all your path declarations to ensure you don't have any white spaces. Also don't forget to source your bash_profile or what ever type of command line shell you use.
I've always been a little wobbly on OSX environment variables, but I figured that, so long as /usr/local/bin was in my $PATH, that everything residing in that folder would be usable as a command in the shell.
This doesn't appear to be happening. $ echo $PATH gives me:
/Users/[username]/.nvm/versions/node/v0.12.7/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
My /usr/local/bin folder contains a symlink to an application; let's call it some-application. But typing some-application in the shell yields the classic bash error:
-bash: some-application: command not found
It was a simple mistake on my part. I had created the symlink using a bad link location:
$ ln -s /some/non-existent/location/some-application /usr/local/bin/some-application
There was no error on creating this 'link'. The symlink name was the one used in the bash error, masking the fact that it couldn't find the original location, not the link.
For me, I would have either expected an error to be thrown on creation of the link, or at least for bash to detail which path couldn't be resolved. Something like this:
-bash: /some/non-existent/location/some-application: No such file or directory
Oh well. Case closed.
P.S
Any light being shed on why it behaves this way might be helpful to myself and others.