I'm trying to make a C++ program that will find the shortest route out of the a maze. I'm struggling to get my makefile to work right now though. Currently, my makefile contains the following:
mazeIO : mazeIO.cpp maze.h
g++ -g -Wall mazeIO.cpp maze.h -o mazeIO
mazeIO.cpp and maze.h are the only two files I have in the project. In the command line I am typing
make -f Makefile
and it compiles fine. Then I am typing
./mazeIO maze.txt
maze.txt is the maze input that I am trying to navigate.
After I type this in I get the following error:
bash: ./mazeIO: Permission denied
I do not understand why. Any suggestions?
This is simple. It needs executable rights.
chmod +x mazeIO
You can also use chmod if it needs to be executed by other users.
man chmod will give you the numeric values needed if it needs to be executed by other users. Be wary of giving full executable, read, and write rights (chmod 777)
chmod 600 will not make it executable.
Executable files are known as executable in Linux due to the presence of the execute (x) flag. Your "executable" doesn't have it - it only has the read (r) and write (w) permissions. Either you strip the permission from the executable (say, using chmod 600 mazeIO), or your umask is weird. umask controls the default user permissions on new files, and if you modified it from the default, it might wreak havoc. The default umask is 0022 for most systems, I suggest it be left there unless you know what will happen. I don't have any other idea why you might be missing the exec bit.
This does not fix the original question as stated, but I will share a possible solution for anyone seeing this same behavior (getting bash: ./mazeIO: Permission denied).
I was getting this error in a project because my Makefile was using the -c flag. This flag lets g++ compile and assemble project files but doesn’t link them, so the compiler creates a file that will appear to be the executable you are expecting but it is not actually an executable. The solution is to remove this flag.
Related
I need your help with an access issue with neofetch on my macOS.
Here the thing, I recently install neofetch on my terminal (oh-my-zsh), it works but, between the firts line (last login) and the logo that displays :
mkdir: /Users/'MYUSERNAME'/.config/neofetch/: Permission denied
/usr/local/bin/Neofetch: line 4476:
/Users/'MYUSERNAME'/.config/neofetch/config.conf: Permission denied
And I don't know why, of course, I did many types of research on google before asking you.
Do you have an idea?
You need to change the permissions for your config directory:
sudo chmod -R 666 /Users/YOURUSERNAME/.config
666 means Read-Write for all users.
Doing the same as garritfra did but with that last directory line you have there worked for me on a windows 10 machine though. It may work for the mac as well?
sudo chmod -R 666 /Users/MYUSERNAME/.config/neofetch/config.conf
Replace MYUSERNAME with whatever is shown in the error.
I was having the same issue and was able to solve this in the following way:
Open up Finder
Reveal hidden folders & files by pressing CMD+>+SHIFT
Locate the .config folder and right click it and click 'get info'.
Under the sharing & permissions section click the small plus and just add the entire Administrators group and remember to change the permissions to read & write for the entire group.
neofetch
Here is a bulletproof one-liner that solves the issue:
sudo chmod -R 710 $HOME/.config
Execute this command in a terminal session.
After restarting your terminal or, alternatively, sourcing your shell configuration file (assuming you have added the neofetch command to that file) with:
source ~/.zshrc
(replacing ~/.zshrc with the path to your shell configuration file if you are using a different one), the error prompt should disappear.
Note that this only gives 'execute' permission to the 'group' class. There is no need, as the currently accepted answer suggests, to give 666 or 777 modes as that needlessly makes your system less secure (not to mention even no. octal figures such as 666 don't even work as they fail to give the required 'execute' permission, which requires an odd number bit).
Modes such as 730, 750, and 770 will work, but unless something changes in neofetch's future update that demands it, it is unnecessarily too generous and I wouldn't advise it.
Finally, there is absolutely no reason to give users in the 'other' class any permission to the ~/.config directory (unless you have a very compelling reason to), and hence the last permission bit (3rd digit in the mode represented by octal numbers) should always remain 0.
enter image description here
PLEASE HELP! I can't seem to run my file. I've compiled it so it should run shouldn't it?
It also happens to my other files and I can't seem to fix it.
Ok, so a quick point of notice:
It is usually appreciated if you post your code directly in your question and use the code markup for that. It makes it easier to answer your question and prevents the image from turning into a dead-link at one point in time.
Then, regarding your code: it seems your Topic3ex1.c still has some errors, it always helps to fix them first. Maybe the errors are preventing Topic3ex1 (which I believe you have selected as the output file with the -o option? I am not familiar with gcc's syntax.) from being formed. Check if the file exist first by executing ls -a from the command line.
If you get a message saying "No such file or directory" while it is indeed there, this is usually caused by a lack of user rights. Try executing chmod u+x Topic3ex1.c and then run your command again. This will give your current user the right to execute the file (read up on chmod if you do not know it already, you will need it often).
Final question: is Topic3ex1 supposed to be a file or a folder? For if it is a file, then executing it like ./Topic3ex1 will only work if it is a shellscript (in that case, best rename your file to Topic3ex1.sh, its best to always mention the extension of the file). If it is a folder the ./ command won't do anything and the cd Topic3ex1 (cq. change directory-)command you where experiencing with will activate it as your working directory. If it is a file however, then the change directory command will, of course, be useless.
I am using a makefile in windows to push some files on a Unix server (here a text file "blob.txt" in the same folder of my makefile).
My makefile script is:
setup:
pscp blob.txt username#hostname:/folder/
I start a command prompt, go in the folder where blob.txt and the makefile are present and type:
make setup
Which results in:
pscp blob.txt username#hostname:/folder/
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [setup] Error 2
In a #fail ... whereas if I enter directly the command in the command prompt:
pscp blob.txt username#hostname:/folder/
It works ... I really wonder why.
The error
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
is almost certainly complaining that Windows cannot find pscp.
This is almost certainly because the value of %PATH% (or whatever) is different when make spawns a shell/console then when you have it open manually.
Compare the values to confirm that. Then either use the full path to pscp in the makefile recipe or ensure that the value of PATH is set correctly for make's usage.
I didn't want to remove GIT's bin folder from the PATH variable (I am using a Windows machine), as I use it quite often. So I looked for a workaround, and here it is:
Add the <git-installation-directory>/usr/bin directory to your PATH variable too. This basically adds the rest of the linux-like commands that come with the "GIT bash" to your environment. After applying this, my makefiles ran normally again. :)
If you are curious about what shell is being invoked by make, just add $(info $(SHELL)) at the beginning of your makefile. The path/name of the shell being invoked is printed to the console as soon as you run make.
I know this is an old question that has been answered, but thought I'd and my experiences for anyone still running into this. I was getting the same cryptic error Colonel Beauvel (though with the windows MOVE command, not pscp):
process_begin: CreateProcess(NULL, move /y foo\bar.c .\baz.c, ...) failed.
make (e=2): The system cannot find the file specified.
Our CI was running the same Makefile and working perfectly. Turns out CI was using mingw32-make and I was using GNU make. Uninstalling GNU make (which got installed as part of an unrelated bulk package) and aliasing mingw32-make to 'make' works perfectly.
#user3869623's solution works for me. I'd like to share some details of mine to complete the picture.
My makefile contains below target:
clean:
#echo '$(OS)'
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
When I run make clean, I see this error:
Since it says something went wrong with echo, so I change my makefile target to below:
clean:
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
This time, make clean gives me this error:
I am surprised to see bash here since I am working in Windows command line.
Then I checked my %PATH%, I see this entry:
C:\DevTools\Git\bin
There's a bash.exe and sh.exe in that path. So I removed this entry, and it works fine now.
BUT I STILL DON'T KNOW WHY BASH GET INTO THIS???
ADD 1
As to why the C:\DevTools\Git\bin shows up in my %PATH%, because I am using Sublime and it always asks me for the Git binaries:
In my case, I had git\bin in my %PATH% which contains bash.exe and sh.exe.
Removing %GIT_HOME%\bin from the PATH worked for me.
To build on user3869623's response.
In my case i had git\bin in my %PATH% which contains bash.exe and sh.exe.. Removing %GIT_HOME%\bin from the PATH worked for me
While this recommendation may allow make to run, it will likely cause issues for git, especially if the makefile is installing software from a git repository.
A better solution is to simply change %GIT_HOME%\bin to %GIT_HOME%\cmd
For those who tried removing the git bin folder from PATH and it didn't work for them, search your PATH variables for any paths containing bash.exe.
In my case I found a variable linking to cygwin bin folder C:\cygwin64\bin, removed it and it worked.
I had the same issue, and this thread really helped me solve it. In my case, it was a conflict between make and the sh.exe that was visible through my path, due to both git and mingw64. To fix my issue, without breaking Git, I added these lines to the top of my batch file that calls make:
set path=%path:git\bin=;%
set path=%path:mingw64\bin=;%
set path=%path:usr\bin=;%
This hides the extra sh.exe instances from make for that instance only.
I ran into this problem recently and this question was one of the top hits for my searches.
None of the other answers here helped me. The fix, for me, was to put the binary name in quotes:
setup:
"pscp" blob.txt username#hostname:/folder/
-"pscp" blob.txt username#hostname:/folder/ # Failure is OK, `-` in front
I'm on windows.
By explicitly setting my compiler to gcc (instead of cl?) it solved my problem.
CC = gcc
I hope some people more knowledgeable than me could explain why changing the compiler would impact the makefile parsing.
I feel like I'm missing something very basic so apologies if this question is obtuse. I've been struggling with this problem for as long as I've been using the bash shell.
Say I have a structure like this:
├──bin
├──command (executable)
This will execute:
$ bin/command
then I symlink bin/command to the project root
$ ln -s bin/command c
like so
├──c (symlink to bin/command)
├──bin
├──command (executable)
I can't do the following (errors with -bash: c: command not found)
$ c
I must do?
$ ./c
What's going on here? — is it possible to execute a command from the current directory without preceding it with ./ and also without using a system wide alias? It would be very convenient for distributed executables and utility scripts to give them one letter folder specific shortcuts on a per project basis.
It's not a matter of bash not allowing execution from the current directory, but rather, you haven't added the current directory to your list of directories to execute from.
export PATH=".:$PATH"
$ c
$
This can be a security risk, however, because if the directory contains files which you don't trust or know where they came from, a file existing in the currently directory could be confused with a system command.
For example, say the current directory is called "foo" and your colleague asks you to go into "foo" and set the permissions of "bar" to 755. As root, you run "chmod foo 755"
You assume chmod really is chmod, but if there is a file named chmod in the current directory and your colleague put it there, chmod is really a program he wrote and you are running it as root. Perhaps "chmod" resets the root password on the box or something else dangerous.
Therefore, the standard is to limit command executions which don't specify a directory to a set of explicitly trusted directories.
Beware that the accepted answer introduces a serious vulnerability!
You might add the current directory to your PATH but not at the beginning of it. That would be a very risky setting.
There are still possible vulnerabilities when the current directory is at the end but far less so this is what I would suggest:
PATH="$PATH":.
Here, the current directory is only searched after every directory already present in the PATH is explored so the risk to have an existing command overloaded by an hostile one is no more present. There is still a risk for an uninstalled command or a typo to be exploited, but it is much lower. Just make sure the dot is always at the end of the PATH when you add new directories in it.
You could add . to your PATH. (See kamituel's answer for details)
Also there is ~/.local/bin for user specific binaries on many distros.
What you can do is add the current dir (.) to the $PATH:
export PATH=.:$PATH
But this can pose a security issue, so be aware of that. See this ServerFault answer on why it's not so good idea, especially for the root account.
In KDE, I adjusted a macro to compile and install Python files, but I'm having problem with it keeping the files' permissions.
To be more clear, the offendling line in the macro is
install(FILES ${SOURCE_FILE} DESTINATION ${DESTINATION_DIR})
which works for 99% of the cases.
In one case, though I have a Python file marked as executable (+x, I'm talking about Linux here) in the source directory, which then is symlinked to the installation's binary dir. Since install() does not preserve permissions, the execute bit is stripped from it, and this causes all sorts of problems later on.
Is it possible to keep the file's permissions, or to read them and set them accordingly? I would hate to use a manual chmod command since it's not portable.
EDIT: I do not want to make all files installed by this macro executable, as this would be pointless.
You can install files with +x permission using
install(PROGRAMS ...
command.
Alternatively, you can install whole directory preserving file permissions:
install(DIRECTORIES ... USE_SOURCE_PERMISSIONS)
See documentation for install command for more info.