I'm trying to run basic Linux commands inside a Makefile, but it fails stating that the file is not found. (the file do exists)
Can anyone suggest how to rectify this error?
.PHONY: Checking
Checking:
${INFO} "Checking"
ls -ltr ****/scripts.py
Error:
ls: cannot access '****/scripts.py': No such file or directory
I'm not sure what you expect ****/scripts.py to do, but in /bin/sh means the same thing as */scripts.py and presumably that doesn't exist, hence the error message you're seeing.
I guess you are hoping to use some fancy shell feature that does deep searching if you give multiple * characters. However, make always uses /bin/sh, it never uses your specific shell (imagine what a disaster that would be for portability!) which is typically a POSIX standard shell. In POSIX, filename globbing is quite simple and doesn't support multiple * to mean search subdirectories.
You either have to use find or similar instead:
ls -ltr `find . -name scripts.py`
Or specifically set your shell to whatever you want (note this causes your makefile to be non-portable to systems which don't have your shell):
SHELL := /bin/myshell
Related
When running scripts in bash, I have to write ./ in the beginning:
$ ./manage.py syncdb
If I don't, I get an error message:
$ manage.py syncdb
-bash: manage.py: command not found
What is the reason for this? I thought . is an alias for current folder, and therefore these two calls should be equivalent.
I also don't understand why I don't need ./ when running applications, such as:
user:/home/user$ cd /usr/bin
user:/usr/bin$ git
(which runs without ./)
Because on Unix, usually, the current directory is not in $PATH.
When you type a command the shell looks up a list of directories, as specified by the PATH variable. The current directory is not in that list.
The reason for not having the current directory on that list is security.
Let's say you're root and go into another user's directory and type sl instead of ls. If the current directory is in PATH, the shell will try to execute the sl program in that directory (since there is no other sl program). That sl program might be malicious.
It works with ./ because POSIX specifies that a command name that contain a / will be used as a filename directly, suppressing a search in $PATH. You could have used full path for the exact same effect, but ./ is shorter and easier to write.
EDIT
That sl part was just an example. The directories in PATH are searched sequentially and when a match is made that program is executed. So, depending on how PATH looks, typing a normal command may or may not be enough to run the program in the current directory.
When bash interprets the command line, it looks for commands in locations described in the environment variable $PATH. To see it type:
echo $PATH
You will have some paths separated by colons. As you will see the current path . is usually not in $PATH. So Bash cannot find your command if it is in the current directory. You can change it by having:
PATH=$PATH:.
This line adds the current directory in $PATH so you can do:
manage.py syncdb
It is not recommended as it has security issue, plus you can have weird behaviours, as . varies upon the directory you are in :)
Avoid:
PATH=.:$PATH
As you can “mask” some standard command and open the door to security breach :)
Just my two cents.
Your script, when in your home directory will not be found when the shell looks at the $PATH environment variable to find your script.
The ./ says 'look in the current directory for my script rather than looking at all the directories specified in $PATH'.
When you include the '.' you are essentially giving the "full path" to the executable bash script, so your shell does not need to check your PATH variable. Without the '.' your shell will look in your PATH variable (which you can see by running echo $PATH to see if the command you typed lives in any of the folders on your PATH. If it doesn't (as is the case with manage.py) it says it can't find the file. It is considered bad practice to include the current directory on your PATH, which is explained reasonably well here: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html
On *nix, unlike Windows, the current directory is usually not in your $PATH variable. So the current directory is not searched when executing commands. You don't need ./ for running applications because these applications are in your $PATH; most likely they are in /bin or /usr/bin.
This question already has some awesome answers, but I wanted to add that, if your executable is on the PATH, and you get very different outputs when you run
./executable
to the ones you get if you run
executable
(let's say you run into error messages with the one and not the other), then the problem could be that you have two different versions of the executable on your machine: one on the path, and the other not.
Check this by running
which executable
and
whereis executable
It fixed my issues...I had three versions of the executable, only one of which was compiled correctly for the environment.
Rationale for the / POSIX PATH rule
The rule was mentioned at: Why do you need ./ (dot-slash) before executable or script name to run it in bash? but I would like to explain why I think that is a good design in more detail.
First, an explicit full version of the rule is:
if the path contains / (e.g. ./someprog, /bin/someprog, ./bin/someprog): CWD is used and PATH isn't
if the path does not contain / (e.g. someprog): PATH is used and CWD isn't
Now, suppose that running:
someprog
would search:
relative to CWD first
relative to PATH after
Then, if you wanted to run /bin/someprog from your distro, and you did:
someprog
it would sometimes work, but others it would fail, because you might be in a directory that contains another unrelated someprog program.
Therefore, you would soon learn that this is not reliable, and you would end up always using absolute paths when you want to use PATH, therefore defeating the purpose of PATH.
This is also why having relative paths in your PATH is a really bad idea. I'm looking at you, node_modules/bin.
Conversely, suppose that running:
./someprog
Would search:
relative to PATH first
relative to CWD after
Then, if you just downloaded a script someprog from a git repository and wanted to run it from CWD, you would never be sure that this is the actual program that would run, because maybe your distro has a:
/bin/someprog
which is in you PATH from some package you installed after drinking too much after Christmas last year.
Therefore, once again, you would be forced to always run local scripts relative to CWD with full paths to know what you are running:
"$(pwd)/someprog"
which would be extremely annoying as well.
Another rule that you might be tempted to come up with would be:
relative paths use only PATH, absolute paths only CWD
but once again this forces users to always use absolute paths for non-PATH scripts with "$(pwd)/someprog".
The / path search rule offers a simple to remember solution to the about problem:
slash: don't use PATH
no slash: only use PATH
which makes it super easy to always know what you are running, by relying on the fact that files in the current directory can be expressed either as ./somefile or somefile, and so it gives special meaning to one of them.
Sometimes, is slightly annoying that you cannot search for some/prog relative to PATH, but I don't see a saner solution to this.
When the script is not in the Path its required to do so. For more info read http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html
All has great answer on the question, and yes this is only applicable when running it on the current directory not unless you include the absolute path. See my samples below.
Also, the (dot-slash) made sense to me when I've the command on the child folder tmp2 (/tmp/tmp2) and it uses (double dot-slash).
SAMPLE:
[fifiip-172-31-17-12 tmp]$ ./StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ /tmp/StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ mkdir tmp2
[fifi#ip-172-31-17-12 tmp]$ cd tmp2/
[fifi#ip-172-31-17-12 tmp2]$ ../StackO.sh
Hello Stack Overflow
I'm the author of a utilty that makes compressing projects using zip a bit easier, especially when you have to compress regularly, such as for updating projects submitted to an application store (like Chrome's Web Store).
I'm attempting to make quite a few improvements, but have run into an issue, described below.
A Quick Overview
My utility's command format is similar to command OPTIONS DEST DIR1 {DIR2 DIR3 DIR4...}. It works by running zip -r DEST.zip DIR1; a fairly simple process. The benefit to my utility, however, is the ability to use a predetermined file (think .gitignore) to ignore specific files/directories, or files/directories which match a pattern.
It's pretty simple -- if the "ignorefile" exists in a target directory (DIR1, DIR2, DIR3, etc), my utility will add exclusions to the zip -r DEST.zip DIR1 command using the pattern -x some_file or -x some_dir/*.
The Issue
I am running into an issue with directory exclusion, however, and I can't quite figure out why (this is probably be because I am still quite the sh novice). I'll run through some examples:
Let's say that I want to ignore two things in my project directory: .git/* and .gitignore. Running command foo.zip project_dir builds the following command:
zip -r foo.zip project -x project/.git/\* -x project/.gitignore
Woohoo! Success! Well... not quite.
In this example, .gitignore is not added to the compressed output file, foo.zip. The directory, .git/*, and all of it's subdirectories (and files) are added to the compressed output file.
Manually running the command:
zip -r foo.zip project_dir -x project/.git/\* -x project/.gitignore
Works as expected, of course, so naturally I am pretty puzzled as to why my identical, but dynamically-built command, does not work.
Attempted Resolutions
I have attempted a few different methods of resolving this to no avail:
Removing -x project/.git/\* from the command, and instead adding each subdirectory and file within that directory, such as -x project/.git/config -x project/.git/HEAD, etc (including children of subdirectories)
Removing the backslash before the asterisk, so that the resulting exclusion option within the command is -x project/.git/*
Bashing my head on the keyboard in angst (I'm really surprised this didn't work, it usually does)
Some notes
My utility uses /bin/sh; I would prefer to keep it that way for maximum compatibility.
I am aware of the git archive feature -- my use of .git/* and .gitignore in the above example is simply as an example; my utility is not dependent on git nor is used exclusively for projects which are git repositories.
I suspected the problem would be in the evaluation of the generated command, since you said the same command when executed directly did right.
So as the comment section says, I think you already found the correct solution. This happens because if you run that variable directly, some things like globs can be expanded directly, instead of passed to the command. And arguments may be messed up, depending on the situation.
Yes, in that case:
eval $COMMAND
is the way to go.
I'm having the infamous Argument list too long error when running ocamldep with a large number of input files.
This issue only happens when using a native Windows OCaml compiler + Cygwin: in this configuration, ARG_MAX returns 32000, an awfully low value, which I believe is a limit imposed by Windows itself, not Cygwin.
The usual solution for this kind of error is to use xargs, if we can split the arguments, such as when using ls or rm, but I don't know how it could work with ocamldep. Since it expects all files to be given in the command line at the same time (to properly compute dependencies), and there seems to be no option to give the list of files in a file (as in -f filelist.txt), is there a way to avoid this issue?
You can use xargs since you do not need to list all the files for ocamldep at once.
For example, in OCaml compiler's source code, to know the dependencies of GraphicsX11 over Graphics, you do not need to list graphcs.ml
$ cd otherlibs/graphics
$ ocamldep graphicsX11.ml
graphicsX11.cmo : graphics.cmi graphicsX11.cmi
graphicsX11.cmx : graphics.cmx graphicsX11.cmi
However, you must make dependees accessible ocamldep, otherwise they are ignored. Actually GraphicsX11 depends on Hashtbl too, and it is found with -I dir option:
# Seek dependencies over stdlib modules too:
$ ocamldep -I ../../stdlib/ graphicsX11.ml
graphicsX11.cmo : ../../stdlib/hashtbl.cmi graphics.cmi graphicsX11.cmi
graphicsX11.cmx : ../../stdlib/hashtbl.cmx graphics.cmx graphicsX11.cmi
(Personally I have never seen an OCaml project more than 32000 ml/mli files. Wow.)
I want to create one unix command, which will unzip the folder.
so, I am searching for the code, but I am not aware that how should I use such code to make Unix command?
I have gone through various questions & answers but I don't get any perfect information.
So, can any one please suggest me any code (in C++ or C or any language to make exe) and to use it as a Unix command.
NOTE: I know command like 'unzip' is available in 'Mks toolkit' type of software but we can not use it, so I want to make command which can run through 'command prompt'
If you want to add a command, you only need to create your executable and put its link in the /usr/bin folder.
Just compile your code and set a link to it's executable like this:
ln -s /path/to/your_executable /usr/bin/command_name
If there exists a command that you need to modify, you should set an alias to it. For example, you want ls -1 to run whenever ls is used, then you only need to use the command:
alias ls=ls -1
or put the same command in the .bashrc file in your home directory.
Crossbridge allows you to compile C/C++ programs to target the flash runtime. It comes with its own modified gcc within cygwin. Since SDL only provides developmental zips for VC or mingw, I'm trying to compile SDL within this cygwin environment. However Crossbridge's gcc is version 4.2.1 and according to google searches SDL cannot be compiled with gcc versions higher than 3 inside cygwin. When I run ./configure, it fails with:
*** Your compiler (/cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/g
cc.exe -jvmopt=-Xmx1G) does not produce Win32 executables!
When I just type gcc alone, I get:
bash: /usr/bin/gcc: cannot execute binary file
Does it make a difference if I compile SDL using one compiler (i.e., a lower version of gcc) and attempt to use it with the Crossbridge compiler?
Is there a workaround for this?
I checked the Crossbridge_1.0.1.zip, cc and gcc maybe are broken link (only 56 bytes?) but the gcc-4 seem to be good.
edit
type gcc-4 as you typed gcc from the bash and you'll see the usual expected no input files gcc's error message, try gcc-4 -v
the message Your compiler does not produce Win32 executables is given by the fact that whatever you've executed (or has been executed automatically) is using /cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/gcc.exe as your compiler, but as you already checked it doesn't work, and if you check it with ls -l /usr/bin/gcc.exe you'll see that this is only 56 bytes size, this can't be the real compiler, I guess it probably was a symbolic link to the real compiler, which for some reason isn't working as expected (on linux executing a symlink is as executing the real binary).
I'm not an expert of cygwin, but I guess at some level symlink are supported, reading this FAQ make me wonder if some attribute hasn't lost packaging/unpackaging the zip, so that the symlink aren't recognized.
Try to recreate it (it worked for me):
cd /usr/bin # change directory
rm gcc.exe # remove the broken link
ln -s gcc-4.exe gcc.exe # re-create the symlink
run gcc again, should return the no input files error as expected.
But this isn't the solution, because probably in the unzipped files there are many broken symlink.
I can't believe Adobe is distributing a broken SDK, so perhaps there's some instruction somewhere about how to properly unzip the SDK preserving the symlinks (maybe unzip have a preserve attribute option? I don't know much about zip sorry.
edit
execute the run.bat (the bash) and cd to the main directory where you unzipped the SDK (mine is /cygdrive/c/crossbrige)
cd /cygdrive/c/crossbrige
for f in $(find ./ -type f -print0 | xargs -0 grep '!<symlink>' -l); do attrib +S $f; done
this should hopefully fix all the broken symlink, the only side-effect is that any file containing !<symlink> will get set the attribute DOS SYSTEM, but cygwin check both this magic string at offset 0 and the S attribute to consider a file as a symlink, so hopefully will not break anything.
I used Alex find/ attribute loop to fix all broken links in my cygwin install. I have no idea why they appeared.
The first attempt failed with messages like:
Invalid switch - /usr/lib/terminfo
for each file attrib worked on.
Turned out that for my cygwin/Windows combo I had to cd into the directory and execute attrib from there. So the loop content was:
do cd $(dirname $f); attrib +S $(basename $f); done