I'm experiencing a strange problem with a makefile. I simply want to set a symbolic link in the makefile but get an error message on one machine (Linux 2.6.18-238.12.1.el5)
make: execvp: ln: Too many levels of symbolic links
It works perfectly fine on my MacBook. It also works fine if I execute the same command in the shell. What could go wrong? Are there any environment variables important for ln?
The execvp in the error message is the key, I think. I believe it is saying there are too many levels of symbolic links while trying to locate the ln command itself.
Example:
all:
ln -nsf /tmp/foo /tmp/foo
/tmp/foo/ln x y
Running "make" with this Makefile errors out with:
make: execvp: /tmp/foo/ln: Too many levels of symbolic links
So, how is your Makefile invoking ln, exactly? What is in your PATH etc.?
[update]
I bet the Makefile is messing up your PATH. Here is a Makefile that reproduces your exact error message:
PATH=/tmp/foo
all:
/bin/ln -nsf /tmp/foo /tmp/foo
ln x y
Related
so i want to start tomcat server, to do this i have to run a script whose path is the following:
/usr/local/Cellar/tomcat/9.0.6/libexec/bin/strartup.sh
Since it is tedious to remember this, i made a simbolic link:
tomcatsh/startup.sh
so with the ln command tomcatsh points to /usr/local/Cellar/tomcat/9.0.6/libexec/bin
There is a problem when i run the shortened version, it yelds an error saying that the startup.sh script couldn't find setclasspath.sh .
this other script is in the same folder, and it is not missing, why doesn't startup find that script? What can i do to solve this problem?
If previously that symlink is defined for the folder of the file, you have to call command with update parameter
ln -sf <file> <symlink>
rather than creation parameter
ln -s <file> <symlink>
kdevelop provides this AppImage binary:
wget -O KDevelop.AppImage https://download.kde.org/stable/kdevelop/5.1.1/bin/linux/KDevelop-5.1.1-x86_64.AppImage
chmod +x KDevelop.AppImage
./KDevelop.AppImage
It works well. So I want to make a soft link called kd to that binary in /usr/bin, eg:
/usr/bin/sudo ln -s KDevelop-5.1.1-x86_64.AppImage kd
Now if I run kd file1, I'd expect that it would open a file name file1 in the current folder, but it always tries to open a file name file1 in my home folder - which is not where it should be.
Is there some way to fix this issue?
Some possible causes:
The application always assumes that you want to open files in your home directory, effectively or literally prepending $HOME to the path. This would be a bug in any *nix program, and should be reported.
The application behaves differently when $(basename "$0") is not KDevelop.AppImage (what #Scheff said).
You are actually running a different kd.
Possible workarounds/investigations:
Pass the full path to the file on the command line. If it tries to open /home/you//full/path/you/provided it is obviously buggy, and you have a test case. If it does not, then there might be some gotcha to what your $PWD actually is. Try checking its value before running.
Symlink with the same name, using sudo ln -s KDevelop-5.1.1-x86_64.AppImage /usr/bin, and try running that. If it behaves the same, you've at least proven that the symlink is not the problem.
Run type -a kd and verify that your /usr/bin/kd comes up first. If not there might be an alias or shell built-in which takes precedence.
That said, what is the actual error message?
I want to disallow a program from keeping local files, and I thought I would accomplish that by pointing a shortcut with its local folder's name to /dev/null, but I cannot seem to get it working.
If I try ln .app /dev/null, I get a message saying
ln: ‘.app’: hard link not allowed for directory
And if I add symbolic, by doing ln .app /dev/null -s, then I get
ln: failed to create symbolic link ‘/dev/null’: File exists
So I don't really know how to accomplish this idea. What is the correct solution?
You should be using:
ln -s /dev/null .app
to create a symlink called .app pointing to /dev/null
Recently I have installed a program called "paradigm". In the program path (/home/hora/Paradigm/) there is a directory "testdata" (/home/hora/Paradigm/testdata) which includes a shell script that runs an example test of the application.The first time I installed the program I was able to run the shell script(runtests.sh) but now that I try to run it I get the error of " No such file or directory", although the files which is mentioned by the error are there. I am sure the problem is due to lack of my knowledge to linux and your help will be appreciated. To show the situation:
hora#serv:~/Paradigm/testdata$ ./runtests.sh
Testing node splitting [1/2], should take seconds
diff: needs_split_1.out: No such file or directory
./runtests.sh: line 6: ../pathwaytab2daifg: No such file or directory
But if I list the content of directory the mentioned files are there:
hora#serv:~/Paradigm/testdata$ ls
complex_family_pathway.tab needs_split_1.cfg needs_split_2.out runtests.sh small_disconnected_pathway.tab
complex_family_pathway.tab.out needs_split_1.out needs_split_2.pathway.tab
And then:
hora#serv:~/Paradigm$ ls
common.h configuration.o
evidencesource.o helperScripts makefile
pathwaytab2daifg.cpp pathwaytab.h test1 configuration.cpp
evidencesource.cpp externVars.cpp main.cpp paradigm
pathwaytab2daifg.o pathwaytab.o testdata configuration.h
evidencesource.h externVars.o main.o pathwaytab2daifg
pathwaytab.cpp README.mediawiki
This is the script content(the problematic part):
#!/bin/bash
set -o pipefail
cd
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
I believe the authors of this script want you to set HOME to ~/Paradigm, or they expect you to install directly in your HOME directory (~) rather than in ~/Paradigm. Either way, this is an error on their part. A simple fix may be to move the installation to ~, or try:
env HOME=$(pwd) ./runtests.sh
(Note that the env is not necessary unless you are running a csh family shell such as csh or tcsh). Setting HOME changes the behavior of cd when called with no arguments and makes the value of HOME the target directory.
This line:
#!/bin/bash
set -o pipefail
cd #<----- here!
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
is changing the directory to ~/, which is the default argument of cd if you don't pass a path to it (see here).
You could fix the script to work from anywhere if you like, by giving cd an absolute path i.e. changing that cd line to cd /home/hora/Paradigm/testdata.
I know this is a VERY old question BUT I think my answer is relevant for others that did not find their answer.
I've been using Linux on a home server since about 2000. Recently, I've upgraded a home server to 64-bit architecture (DELL R510 w/ 2 # Xeon).
I've been using a program (text2pdf.c) since my 32-bit kernel 2.4.32 days. I had forgotten to clean and re-make the executable file before installing it on the 64-bit system. Hence, I received the same error BUT not for the reasons stated in all the answers I've found online. 'which' and 'type' gave no clues BUT using 'file' gave me the info on the libraries that were linked at compile time and they were 2.4.32 libraries. Obviously, OLD 32-bit libraries on a 4.x 64-bit kernel didn't fly. Make clean, make (and make install) cleared the problem.
Peace and blessings,
JQ
I am using FORTRAN to solve partial differentiate equations. Main program and subroutines have been put in .f file. And I got a .sh file to compile the commands in source code in linux operating system. This file has been attached. But I failed to run this. After struggling for a week, I really need some help on this. Please any help would be greatly appreciated!!!
#!/bin/bash
#
mkdir temp
cd temp
rm *
~/binc/$ARCH/f77split ../fishpack.f
#
for FILE in `ls -1 *.f`;
do
gfortran -c -g $FILE >& compiler.txt
if [ $? -ne 0 ]; then
echo "Errors compiling " $FILE
exit
fi
rm compiler.txt
done
rm *.f
#
ar qc libfishpack.a *.o
rm *.o
#
mv libfishpack.a ~/libf77/$ARCH
cd ..
rmdir temp
#
echo "Library installed as ~/libf77/$ARCH/libfishpack.a."
This looks like the shell script is simply trying to compile a fortran file, but instead of using gfortran's internal toolchain, it is compiling parts manually then linking them together. I have a feeling (though I haven't confirmed) that the call to the program ar is bad, even if it got that far (I'm guessing it should be ar -qc instead of ar qc.).
Anyway, if all the source is in a single fortran file that someone else gave you (fishpack.f), you might be able to compile the whole thing with a single call to gfortran:
gfortran fishpack.f
It should create (by default) an output executable with a filename a.out. If the fortran code is not structured such that it can be lumped into a single file, you may need to work on separating some things out (--as well as updating to at least f90, though that's an aside--).
Good luck.