Mac Os Mavericks
added bin folder to home
added to .bash_profile this:
export PATH=$PATH;$HOME/bin
changed owner of .bash_profile to me (paul)
source ~/.bash_profile generates
/Users/paul/.bash_profile:4: permission denied: /Users/paul/bin
ls -la $HOME/bin is
drwxr-xr-x 2 paul staff 68 Aug 31 08:58 .
drwxr-xr-x+ 55 paul staff 1870 Aug 31 09:33 ..
What am I missing?
When you write
export PATH=$PATH;$HOME/bin
you actually have two commands export PATH=$PATH (that basically does nothing), and then $HOME/bin, which is expanded to /Users/paul/bin, and causes an error since you cannot execute a directory.
It should probably be
export PATH=$PATH:$HOME/bin
# ^
# + -------- colon (:) instead of semicolon (;)
Related
I made a simple program in ruby. The file has the shebang at the top and it is executable. When I run it (./parser.rb), it works.
I then created a symlink using ln -s parser.rb refs.
I then moved this symlink to /usr/local/bin. I restarted my terminal and ran refs, this gave me the following message:
zsh: command not found: refs
I cheched my path variable:
jonaseveraert#MacBook-Air-van-Jonas bin % echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Users/jonaseveraert/.cargo/bin
So that seems fine. I then went into the directory /usr/local/bin looked for the file:
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l | grep refs
lrwxr-xr-x# 1 jonaseveraert staff 9 25 jan 14:14 refs.rb -> parser.rb
So, the file is there, but running it inside of the directory gives me:
jonaseveraert#MacBook-Air-van-Jonas bin % ./refs
zsh: no such file or directory: ./refs
Is there anything I'm forgetting here? I can't seem to find an answer to this.
I have found the solution here. The problem was that I made the symlink inside of the same directory as parser.rb and then moved it to /usr/local/bin
When running
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l | grep refs
lrwxr-xr-x# 1 jonaseveraert staff 9 25 jan 14:14 refs.rb -> parser.rb
It shows that refs.rb is pointing to parser.rb in the same directory, but it's parser.rb that isn't there (because it's in another directory).
So, I executed /Users/jonaseveraert/Documents/projects/academic/parser/parser.rb refs inside of /usr/local/bin and now:
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l refs
lrwxr-xr-x 1 jonaseveraert admin 65 25 jan 15:36 refs -> /Users/jonaseveraert/Documents/projects/academic/parser/parser.rb
The file is now pointing to the right file and can be executed using refs.
I deleted a system directory because Carbon Copy Cloner was unable to back it up and suggested replacing it. After deleting and restarting it was rebuilt by the system. However I could not delete the directory from the trash using standard methods or Terminal commands - even logged in as root. Even after disabling System Integrity Protection I had no luck.
Finder says:
The operation can’t be completed because the item “powerlog” is in use.
File was located here:
private>var>db>powerlog>
The directory that was recreated by the system contains subfolders and files but the directory in the trash has none:
sh-3.2# ls -la /Users/admin/Desktop/powerlog
total 0
drwxrwxrwx 3 root wheel 96 Oct 29 16:37 .
drwx------+ 9 admin staff 288 Nov 14 13:18 ..
Attempting rm -R give this result:
sh-3.2# rm -R /Users/admin/.Trash/powerlog
rm: /Users/admin/.Trash/powerlog: Directory not empty
I could not delete it after logging in as root either.
It appears no application is using the folder:
sh-3.2# lsof /Users/admin/.Trash/powerlog
sh-3.2#
I downloaded go1.7.5.darwin-amd64.tar.gz for osx 10.12.2.
Unpacked the tar and went to the /bin directory to see if the Go executable would run.
$ cd Downloads/go/bin
$ ls
total 54560
-rwxr-xr-x# 1 bryanwheelock staff 9884220 Feb 10 16:53 go
-rwxr-xr-x# 1 bryanwheelock staff 15065500 Feb 10 16:53 godoc
-rwxr-xr-x# 1 bryanwheelock staff 2976976 Feb 10 16:53 gofmt
bryanwheelock#Bryans-MacBook Fri Feb 10 16:57:45 ~/Downloads/go/bin
$ go version
-bash: go: command not found
When you type a command without giving the full path, your system will try to find it within all the folders provided in $PATH variable.
In typical Unix environment, your $PATH does not include "your current folder". So you need to either:
call go by its full path (i.e. $HOME/Downloads/go/bin/go); or
call go by its relative path (i.e. ./go); or
put $HOME/Downloads/go/bin in your $PATH variable; or
put . (Unix way of saying "your current folder") in your $PATH; or
put your go binary into folders that already in your $PATH. For example
sudo cp $HOME/Downloads/go/bin/* /usr/local/bin/.
sudo chmod +x go
seems like it does not have execute permission, so just change permission and run it then you should alias your go binary path to your environment to access binary every where.
I am trying to set adb path so I can access it easily from any directory.To set the path I am trying to edit the .bash_profile to insert the following line :
export PATH=$PATH:/Users/anshulsinghla/Library/Android/sdk/platform-tools/
Command I use to open file: open -e .bash_profile
But I always get a prompt saying "You Don't own the file .bash_profile and don't have permission to write to it. You can duplicate this document and edit the duplicate.Only the duplicate will include your changes".
I tried checking the who is the owner and what permission do they have with following command :
ls -la ~ | grep bash
Output:
-rw------- 1 anshulsinghla staff 6820 Jun 22 10:09 .bash_history
-rw-r--r-- 1 anshulsinghla staff 659 Jun 22 10:11 .bash_profile
It clearly shows I am the owner of the file and I do have read/write permissions but why it never let me edit the file, someone please help me.
Thanks
All the diagnostics have been using ~, so try:
open -e ~/.bash_profile
What did we learn from this? When diagnosing an error, always use exactly the same filename as was used in the error.
The original command did not try to edit .bash_profile in your home directory, yet in the comments everyone was looking at your home directory.
For example, I have foo.sh with 770 permissions. When I do:
ln -s foo.sh bar.sh
The link bar.sh has 2777 permissions. Why is this? I thought they were meant to be inherited?
The permissions on a symbolic link are largely immaterial. They are normally 777 as modified by the umask setting.
The POSIX standard for symlink() says:
The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-2008 shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified.
POSIX provides an lchown() system call; it does not provide an lchmod() function.
(On my MacOS X 10.7.1, with umask 022, a newly created symlink ends up with 755 permissions; with umask 002, the permissions end up as 775. So, the observation that links are created with 770, 700 etc permissions may be accurate; the permissions settings are still immaterial, and do not affect the usability of the symlink.)
Further investigations about symlinks on RHEL 5 and MacOS X
On Linux (RHEL 5 for x86_64; kernel 2.6.18-128.el5), I only get to see 777 permissions on a symlink when it is created:
$ (ls -l xx.pl; umask 777; ln -s xx.pl pqr; ls -l xx.pl pqr)
-rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
lrwxrwxrwx 1 jleffler rd 5 2011-09-21 10:16 pqr -> xx.pl
-rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
$
I ran that in a sub-shell so the umask setting was not permanent.
On MacOS X (10.7.1), I get to see variable permissions on a symlink:
$ (ls -l xxx.sql; umask 777; ln -s xxx.sql pqr; ls -l xxx.sql pqr)
-rw-r--r-- 1 jleffler staff 1916 Jun 9 17:15 xxx.sql
ls: pqr: Permission denied
l--------- 1 jleffler staff 7 Sep 21 10:18 pqr
-rw-r--r-- 1 jleffler staff 1916 Jun 9 17:15 xxx.sql
$
Note that this is the same command sequence (give or take the file name) linked to.
On MacOS X, the chmod command has an option -h to change the permissions on a symlink itself:
-h If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.
On MacOS X, the permissions on the symlink matter; you can't read the symlink unless you have read permission on the symlink (or you're root). Hence the error in the ls output above. And readlink failed. Etc.
On MacOS X, chmod -h 100 pqr (execute) allows me to use the link (cat pqr works) but not to read the link. By contrast, chmod -h 400 pqr allows me to both read the link and use the link. And for completeness, chmod -h 200 pqr allows me to use the link but not to read it. I assume, without having formally tested, the similar rules apply to group and other.
On MacOS X, then, it seems that read or write permission on a symlink allows you to use it normally, but execute permission alone means you cannot find where the link points (readlink(2) fails) even though you can access the file (or, presumably, directory) at the other end of the link.
Conclusion (subject to modification):
On some versions of Linux, you can only get 777 permission on a symlink.
On MacOS X, you can adjust the permissions on a symlink and these affect who can use the symlink.
The MacOS X behaviour is an extension of the behaviour mandated by POSIX - or deviation from the behaviour mandated by POSIX. It complicates life slightly. It means that you have to ensure that anyone who is supposed to use the link has permission to do so. This is normally trivial (umask 022 means that will be the case).
The underlying system call for chown -h on MacOS X is setattrlist(2).
http://en.wikipedia.org/wiki/Symbolic_link
The file system permissions of a symbolic link usually have relevance
only to rename or removal operations of the link itself, not to the
access modes of the target file which are controlled by the target
file's own permissions.
The permissions for the link are just that. What it points to still has it's own permissions.