I can't figure out how to add a directory to the system path. I found out that the command is something like this:
export PATH=$PATH:/my_path/to/my_dir
Example
I run the terminal in the path where my installation directory is located. In this case I'm talking about Play Framework. And I type:
export PATH=$PATH:/to/play20
It looks like nothing happens. In fact, when I type the command "play" (to execute the framework) I get:
-bash: play: command not found
Can someone please give me a decent step-by-step guide?
Execute the command “/to/play20/play help”. If this gives the expected output (help for the play command), then the executable is available, and the problem is in the shell path. If it does not give the expected output, then the executable is not working.
In the former case, ensure you are running the bash shell. (This is the default for recent versions of Mac OS X, but it may be changed for specific accounts.) To do this temporarily, execute the command “bash”. (When you want to exit the temporary shell, execute the command “exit”.) Then execute the export command again. (When the export command works, it changes the variable without displaying any output, so this is normal.) Check the spelling in the export command carefully.
In the latter case, execute “ls -ld /to/play20/play”. If you get a message that the file does not exist, then the executable is not installed correctly, and I cannot help you further. If the file is present, then it is not executable for some reason. This might be because you do not have permission to access it (especially permission to execute it, marked by “x” in certain places in the initial field of the ls output that may contain hyphens, “r”, “w”, and a few other letters) or that it is a symbolic link to a file that does not exist (indicated by an “l” in the first character of the ls output for the file). Lack of permission can be fixed by the chmod command, assuming you have appropriate permissions for changing permissions on the system. If the file is a symbolic link to another file, you may have a bad installation, or the target file may have permission issues (or be another symbolic link, and so on).
Related
-bash: export: /Users/deboadebayo/Desktop/Coding/:/opt/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.8/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin':
not a valid identifier
The above message is the error message I receive every time I open my terminal. I did create a backup of my bash profile. But essentially now I can no longer navigate anywhere I want to go using command line requests.
Any help would be much appreciated
If you have a backup, use an absolute path to the mv and cp commands to rename your broken file and restore the backup, both without depending on path lookup.
/bin/mv .bash_profile .bash_profile.broken
/bin/cp .bash_profile.backup .bash_profile
Close the current terminal window and open a new one, which should use your working, original .bash_profile to initialize PATH. Now you try to make the correct modification to your PATH.
oops. The easiest way to fix it would be to launch an editor with an absolute path. $PATH only specifies the locations in which the shell will search if told to execute a program relative (or no) path specified. The which program can search the path and shows the first executable found:
$ which vim
/usr/bin/vim
So if you're a vim user, you should be able to run /usr/bin/vim at the command line, and the path won't be relevant. Then you can fix your file in the editor. Looks like my osx machine also has nano if you'd prefer that editor. I don't think I installed it so it probably came shipped with osx I'm guessing:
$ which nano
/usr/bin/nano
If you want to revert to your backup, use cp, but specify it from its absolute position, /bin/cp:
$ /bin/cp first.txt second.txt
Obviously you'll want to change the file names on that one for it to work for you.
If I try to run virtualenv, I get this message:
$ virtualenv
-bash: /Users/me/Library/Python/3.6/bin/virtualenv: No such file or directory
It's not surprising that this happens, because I've removed this directories at an earlier point when trying to clean up my computer from different Python versions. However, how does my system know to look in that directory for virtualenv? I've looked in my bash profile, and there is no mention of virtualenv there.
When you type something your command interpreter has to search the command. Of course it cannot try every possible directory on your system. Then it provides to the user a way to control that process. This is the purpose of the PATH environment variable :
$ echo $PATH
will show you the actual value which looks like dir1:dir2:...:dirn, meaning that commands where searched for in dir1, then dir2, etc. You have to remove the value /Users/me/Library/Python/3.6/bin/ from it. The best way is to edit the .bashrc or .bash_profile file to remove the permanent setting of this variable. Then reconnect.
I was following a Git course on Udacity and we made some changes to our bash profiles.
Somehow my .bash_profile is now recognized as a Unix executable file rather than a TextEdit document. I can still use it as before, but it bothers me that this change has happened. More than anything I would also like to know what is going on under the hood.
Where on my computer (I'm running MacOS) is the data stored that this is an executable? It doesn't have a file extension so how does the computer know? I changed its 'open with' field found in the 'get info' window but it still identifies as an executable.
in unix each file has permission bits which you can see with ls -l. In this case the 'x' bit has been set which means the file is executable. To revert the file back simply execute chmod -x on the file and it will unset the 'x' permission flag making the file a text file.
I am trying to execute a Makefile script and my Mac complains about 7zcat, although I already have 7z installed.
/bin/sh: 7zcat: command not found
Any thoughts on what's missing on my system? Thank you!
I have never used 7zcat before.
However, it looks like it needs to be installed on your system.
https://github.com/essentialkaos/7zcat
Also, after you download install 7zcat you have to give it execute permission with chmod. Finally, you have to execute it by calling its full path for example if you installed it to the directory you are in you would run ./7zcat file.7z or you would add the path to the file to your environment's $PATH variable.
I hope this helps. You might have to do some more research though.
When you open a Terminal window and type 7zcat and hit enter, what happens? Same message? Well, if you cannot use it, why should make be able to use it? Where and how have you installed 7z? Is the folder with the 7z binaries in your PATH? Since if it isn't, of course the command won't be found.
When the system shall run a command, it will search for this command in the directories stored in the PATH variable. Execute echo $PATH in terminal and you will get a colon separated list of directories; only these directories are searched for binaries. So either you must move your binaries to one of these (or put a symlink to one of these) or add the directory with these binaries to the PATH.
Yet there is no official 7z command line installer for MacOS, which brings me back to the original questions "Where and how have you installed 7z?" And are you sure that whatever you installed even includes a 7zcat?
I did try to find the answer online but unfortunately came up empty handed. Searching for './' in combination with other keywords brings up many hits, but none that helped...
Anyhow, as you can probably tell, I am rather new to MacOs. I am running mongo from the shell.
I cd into the /bin folder and start the mongo daemon with:
'./mongod'
.
If I just enter 'mongod', I get the following error:
'-bash: mongod: command not found'
What does the
'./'
in './mongod' stand for? Why is it needed? Why can't I just execute mongo by typing mongod. After all, I am in the correct directory.
After all, I am in the correct directory
But that directory isn't in the PATH. The gist of the matter is that when the shell wants to execute something it looks into a list of directories (specified in a variable called PATH). And the current directory isn't in that list.
As explained in the answer by cnicutar the shell tries to match the command you enter with executables in the directories that are listed in the PATH environment variable.
Although you could add the current directory to the PATH, it's probably not a good idea to do it. This article gives some good reasons why Linux doesn't add it by default:
Its a measure to plug possible security holes. You can't run commands
in the current directory without specifically calling them.
ie ./myscript.sh
To stop nasties writing a vicious shell script, placing the script in
an innocent location such as /tmp and getting root to run the script.
Would root run a nefarious script? If the script was named 'ls' and
root did a listing, the script would automatically run.