Add executable to /usr/local/bin: command not found (macOS) - ruby

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.

Related

Can't rm -R directory MacOS Catalina

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#

Why can't I run the go binary from within the /bin directory?

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.

cygwin 4 bash -c pwd returning different values depending on current working dir

I upgraded from cygwin 3 to 4.
Now I have the following strange behaviour that I did not experience before:
I have cygwin installed in c:\Tools\cygwin.
bash -c pwd produces different output when started from c:\Tools\cygwin than from any other dir:
c:\Tools>cygwin\bin\bash -c pwd
/cygdrive/c/Tools
c:\Tools>cd cygwin
c:\Tools\cygwin>bin\bash -c pwd
/
This is problematic for me because until now I bundled required cygwin binaries in a bin subdirectory to execute shell scripts on Windows.
That is I had batch files that invoke the shell script via bin/bash -f myscript.sh.
And these shell scripts do things like cd .. which does not work now as the current working dir is /!
A workaround is to move cygwin one subdirectory deeper, but I'd like to understand why cygwin behaves like this.
[EDIT]:
It gets even better:
c:\Tools\cygwin>cd bin
c:\Tools\cygwin\bin>bash -c pwd
/usr/bin
And ls when starting from c:\Tools\cygwin shows the right content:
c:\Tools\cygwin>bin\bash -c "/bin/ls -l | /bin/head -5"
total 313
-rw-r--r-- 1 robert.panzer root 53342 Oct 10 13:24 Cygwin-Terminal.ico
-rwxr-xr-x 1 robert.panzer root 63 Oct 10 13:24 Cygwin.bat
-rw-r--r-- 1 robert.panzer root 157097 Oct 10 13:24 Cygwin.ico
drwxr-xr-x+ 1 robert.panzer Domain Users 0 Oct 10 13:22 bin
I guess you upgraded from the Cygwin 1.5.x series (using Bash 3.x) to the 1.7.x series (using Bash 4.x).
There is nothing surprising in Cygwin's behaviour. What surprises me is that it used to do something different.
Your Cygwin uses your c:/Tools/cygwin as its Unix root directory /. Everything inside this is part of the Unix filesystem, so the drive letter stuff is omitted. Everything else outside c:/Tools/cygwin is available under the /cygdrive/<driveletter> mount points.
And now to the /usr/bin stuff. Cygwin's /bin folder is sort of a hardlink to /usr/bin. All the executables are in /usr/bin.

Bash need refresh for accessing new file?

I ran the maven test and it's ended in a terminal. In another terminal, I ls target/surefire-reports and just find no report here. So I cd .. and enter the directory second times, my file is here! So, Bash need refresh for accessing new file? But when I doing something like head file0 > file1 in a terminal, I can find my file instantly with ls in another terminal.
My instruction here:
In the first terminal:
[me#host1 /home/me/interest/target/surefire-reports]
$mvn test
.....
[me#host1 /home/me/interest/target/surefire-reports]
$
(ended)
In the second terminal:
[me#host1 /home/me/interest/target/surefire-reports]
$ls
[me#host1 /home/me/interest/target/surefire-reports]
$ll -al
total 0
[me#host1 /home/me/interest/target/surefire-reports]
$cd ..
[me#host1 /home/me/interest/target]
$cd surefire-reports/
[me#host1 /home/me/interest/target/surefire-reports]
$ls
mycode.txt TEST-mycode.xml
[me#host1 /home/me/interest/target/surefire-reports]
$
It looks like the current directory is being deleted and re-created. This would explain why you can't see anything until you enter the same directory again--the director you're in is actually gone, and a new one by the same name has been created.
This happens because the directory surefire-report you were in has been removed and re-created, so when you run "ls" you try to get the listing of the current directory, which no longer exists. Try having the parent directory as current directory and run ls like this:
[me#host1 /home/me/interest/target]
$ ls surefire-reports
I think this will give the correct listing

Too many levels of symbolic links osx Lion

i'm try to install a libraries but when the make file try to attempt to Developer folder it appear message
Too many levels of symbolic links.
So i try:
Go home folder (cd /)
then i try:
bash-3.2# cd Developer
and this is the output:
bash: cd: Developer: Too many levels of symbolic links
what could be the problem? can you help me?
ls -l
says me
lrwxr-xr-x 1 root wheel 10 14 Mar 09:13 Developer -> /Developer
Use absolute paths when making symlinks:
Doesn't (always) work:
ln -s file ../new/path
Works (more often):
ln -s /full/path/to/old/place/ /full/path/to/new/place/
If go to:
cd /
and ls -la outputs:
lrwxr-xr-x 1 root wheel 10 14 Mar 09:13 Developer -> /Developer
That's a problem. /Developer should be a folder, not a symlink pointing to itself.
Find out where the original /Developer directory is and delete the symlink, so you can create one pointing to it. If you can't find it, consider reinstalling XCode.

Resources