Have you ever wondered why you get the errors Execute permission denied or The parameter list is too long ? These are just a few of the common errors UNIX and Linux novices receive that they may not know how to avoid. This article explains such errors and provides workarounds and resolutions to these and other errors that may crop up.

./foo: 0403-006 Execute permission denied.

So, you have written or perhaps downloaded a new shell script, and you are itching to try it out. That sounds great, but when you attempt to execute the command, you get the error message ./foo: 0403-006 Execute permission denied . Now what? The message may stem from a couple of possible problems:

You do not have adequate permissions to execute the command.

You do not have adequate permissions to the shell you defined inside the script to tell the script how it and the commands inside it should be interpreted.

You do not have adequate permissions to execute the command

The easiest way to verify your permissions is to view who you are logged on to the server as, then look at the output of ls –l :

#id uid=5008(cormany) gid=330(atc) groups=110(sales),201(sshd) #ls ‑l foo ‑rwxrw‑r‑‑ 1 cormany atc 75 Jun 10 18:46 foo Show more Show more icon

According to the above example, you are logged in as user cormany, and the shell script’s owner is cormany with permissions rwx (or Read, Write, and Execute). This does not appear to be the issue, so let’s move on to the next possible cause.

You do not have adequate permissions to the shell you defined inside the script to tell the script how it and the commands inside it should be interpreted

Let’s take a look inside the script:

#cat foo #!/bin/ksh.new echo "This is a just a test" exit 0 Show more Show more icon

It looks like the script is to be interpreted as a Korn shell script, according to the first line. By looking at the permissions of the shell used, you can verify that you can actually use it:

#ls –l /bin/ksh.new ‑r‑xr‑x‑‑‑ 5 bin bin 289072 May 27 19:03 /bin/ksh.new Show more Show more icon

As root, correct the file permissions to the shell you attempted to use, and try again:

Switch users to root: #su ‑ root's Password: Show more Show more icon Confirm that you are root and not the original user: #id uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp) Show more Show more icon Change the permissions of the file in question: #chmod 555 /bin/ksh.new Show more Show more icon Confirm the permission change on the file: #ls ‑l /bin/ksh.new ‑r‑xr‑xr‑x 1 bin bin 289072 Jun 10 18:45 /bin/ksh.new Show more Show more icon Exit su , then return to the original user: #exit #id uid=5008(cormany) gid=330(atc) groups=110(sales),201(sshd) Show more Show more icon Attempt to execute the script again: #./foo This is a just a test Show more Show more icon

Voila! The problem has been solved!

ksh: bar: not found.

You have written another script and named it bar in the ~cormany/scripts directory. The script works perfectly when executing it providing the full path or from the present working directory (~cormany/scripts), but for some reason, it will not work when you’re working from another directory and just typing the script name:

#pwd /home/cormany/scripts #/home/cormany/scripts/bar This is another test #./bar This is another test #cd #pwd /home/cormany #barksh: bar: not found. Show more Show more icon

Everything worked perfectly except for when you change directories and try to execute the script. There are typically three reasons for such an error message:

You do not have permissions to the file you are trying to execute.

The file simply does not exist or is not in the directory you think it should be in.

The file exists and is in the expected location, and you have sufficient permissions to the file.

You do not have permissions to the file you are trying to execute

You know that this is not issue, as you were able to execute the script by providing the fully qualified path as well as from the commands directory. A simple check on the file permissions should help you discover the cause of the problem:

#ls ‑la ~cormany/scripts total 56 drwxr‑xr‑x 2 cormany atc 512 Jun 12 08:30 . drwxr‑xr‑x 6 cormany atc 512 Jun 10 08:21 .. ‑rwxr‑xr‑x 1 cormany atc 42 Sep 06 16:20 amdc ‑rw‑rw‑rw‑ 1 cormany atc 154 Jan 27 23:23 atc ‑rwxr‑xr‑x 1 cormany atc 206 Aug 04 20:57 atc.2 ‑rwxr‑xr‑x 1 cormany atc 48 Jun 12 08:21 bar ‑rwxr‑xr‑x 1 cormany atc 87 Feb 22 16:11 pac Show more Show more icon

Executing on a command such as ~cormany/scripts/atc would fail, as the file only has Read and Write permission for user, group, and other. Simply adjusting the permissions to include Execute would resolve this problem.

If there is another command in a different directory that will not execute—for example, ~cormany/scripts.old/cujo—check the permissions of that file, also:

#ls ‑l ~cormany/other_scripts/cujo ls: 0653‑345 /home/cormany/other_scripts/cujo: Permission denied. Show more Show more icon

At first glance, you do not even have Read permission. Let’s dive into the target directory and see what is going on:

#cd ~cormany/scripts.old/cujo ksh: /home/cormany/other_scripts: Permission denied. #ls ‑l ~cormany/scripts.old/cujo ls: /home/cormany/scripts.old: The file access permissions do not allow the specified action. total 0 Show more Show more icon

What just happened here? This is yet another form of permission error. The permissions problem may not always be on the file itself but a directory in the path to the file to be executed:

#ls ‑ld ~cormany/scripts.old d‑‑‑‑‑‑‑‑‑ 2 cormany atc 512 Jan 22 08:42 /home/cormany/scripts.old Show more Show more icon

Fixing the permissions on the directory path should resolve your execution issues as long as the file in question also has adequate permissions:

#chmod 755 ~cormany/other_scripts #cd ~cormany/other_scripts #ls –l cujo ‑rwxr‑xr‑x 1 cormany atc 48 Jan 26 08:21 cujo Show more Show more icon

Now, back to the original problem with ~cormany/scripts/bar.

The file simply does not exist or is not in the directory you think it should be in

Again, using the command ls to perform a quick spot check should show whether the file is there:

#ls ‑l ~cormany/scripts/bar ‑rwxr‑xr‑x 1 cormany atc 48 Oct 05 08:21 /home/cormany/scripts/bar Show more Show more icon

If the file did not exist in the directory you originally thought, you would receive the following message:

#ls ‑l ~cormany/scripts/bar ls: 0653‑341 The file /home/cormany/scripts/bar does not exist. Show more Show more icon

If you think the file is somewhere in user cormany’s home directory, you could (provided you had ample permissions) search for the file with the find command:

#find ~cormany ‑name "bar" ‑ls 16409 1 ‑rwxr‑xr‑x 1 cormany atc 48 Sep 06 08:06 /home/cormany/atc/bar 590040 1 ‑rwxr‑xr‑x 1 cormany atc 48 Sep 09 08:42 /home/cormany/test/bar Show more Show more icon

The file exists and is in the expected location, and you have sufficient permissions to the file

The previous methods of execution have been either supplying the fully qualified path to the command in question or sitting directly in the files directory and entering the present working directory to execute (that is, using ./ ). Now that you are not in the commands directory and are not entering the full path, let’s check the value of the PATH environment variable:

#echo ${PATH} /usr/bin:/etc:/usr/sbin:/usr/ucb:/bin:/usr/bin/X11:/sbin:/usr/ java5/jre/bin:/usr/java5/bin:/usr/ushare/bin:/usr/local/bin Show more Show more icon

Aha! The directory /home/cormany/scripts is not in your path. Again, there are two things you could do to fix this problem:

Add ~cormany/scripts to your PATH. Although this change may be easy to make, please keep in mind that every time you add a directory to your PATH variable, you are requesting that the shell search through yet another directory for a command. If you add 10 directories over time, that adds 10 more directories for the shell to search until it returns results that it could not find a file. If you still want to continue, simply perform the following commands: #export PATH=${PATH}:/home/cormany/scripts #echo $PATH /usr/bin:/etc:/usr/sbin:/usr/ucb:/bin:/usr/bin/X11:/sbin:/usr/ java5/jre/bin:/usr/java5/bin:/usr/ushare/bin:/usr/local/bin:/ home/cormany/scripts Show more Show more icon Note: It is rarely wise to add the path to the beginning of the user’s PATH variable. Doing so could result in the execution of unwanted commands. If you feel you must place a path at the beginning, proceed with caution.

Although this change may be easy to make, please keep in mind that every time you add a directory to your PATH variable, you are requesting that the shell search through yet another directory for a command. If you add 10 directories over time, that adds 10 more directories for the shell to search until it returns results that it could not find a file. If you still want to continue, simply perform the following commands: It is rarely wise to add the path to the beginning of the user’s PATH variable. Doing so could result in the execution of unwanted commands. If you feel you must place a path at the beginning, proceed with caution. Move (or copy) the script in question to a directory already in your PATH variable. This can be a good solution if multiple users could benefit from the script. If this is the case, users typically place their files in /usr/local/bin.

ls: 0653-341 The file . does not exist.

You are working in a directory named ~cormany/scripts. All of a sudden, none of the scripts in the directory can be found, and you get a strange message that the present working directory no longer exists:

# ls ‑l total 40 ‑rwxr‑xr‑x 1 cormany atc 42 Sep 06 16:20 amdc ‑rw‑rw‑rw‑ 1 cormany atc 154 Jan 27 23:23 atc ‑rwxr‑xr‑x 1 cormany atc 206 Aug 04 20:57 atc.2 ‑rwxr‑xr‑x 1 cormany atc 48 Jun 12 08:21 bar ‑rwxr‑xr‑x 1 cormany atc 87 Feb 22 16:11 pac #./bar This is another test #pwd /home/cormany/scripts #./barksh: ./bar: not found. #ls ‑l ls: 0653‑341 The file . does not exist. Show more Show more icon

When something like this happens, it means the directory you were once working in has been destroyed via the command rm . Simply creating a new directory with the same name will not correct this problem, as the file descriptor is different.

More times than not, the person afflicted with this error is the same person who caused it in another window (at least, in my case). To safeguard against such accidents, rename the directory via the mv command. By renaming the directory, the users in the original directory can continue to work in a different directory name, as the file descriptor remains the same:

# ls ‑l total 40 ‑rwxr‑xr‑x 1 cormany atc 42 Sep 06 16:20 amdc ‑rw‑rw‑rw‑ 1 cormany atc 154 Jan 27 23:23 atc ‑rwxr‑xr‑x 1 cormany atc 206 Aug 04 20:57 atc.2 ‑rwxr‑xr‑x 1 cormany atc 48 Jun 12 08:21 bar ‑rwxr‑xr‑x 1 cormany atc 87 Feb 22 16:11 pac #./bar This is another test #pwd /home/cormany/scripts Show more Show more icon

Similarly, in another session, someone renames the directory you are working in to ~cormany/scripts.20090601. Thankfully, by just moving and renaming the directory, your work continues without issue:

#./bar This is another test #pwd /home/cormany/scripts.20090601 Show more Show more icon

./foo: /usr/bin/ls: 0403-027 The parameter list is too long.

A program has been running for months on your IBM® AIX® computer without issue. But while the program is running, it creates a file every few minutes in the same directory for logging. The file names begin with f. and e. . The directory is becoming full, and the ls command is slowing down drastically on response time. That is understandable, because the directory has so many files in it.

A few more months go by, and the AIX program continues to run consistently and without problem. There are now 100,000 files that begin with f. and another 100,000 files that begin with e. Now, when you attempt to clean up the log directory of only the files that begin with f., you receive the following message:

#rm ~cormany/logs/f.∗ ksh: /usr/bin/rm: 0403‑027 The parameter list is too long. Show more Show more icon

I guess you waited too long before cleaning up the files. No time like the present, however.

When executing a command like delete , all arguments are validated and expanded before execution. The example provided is looking for ~cormany/logs/f.* , which expands to become 100,000 arguments to the command rm . In other words, instead of rm ~cormany/logs/f.* , what is actually being executed is rm ~cormany/logs/f.1 ~cormany/logs/f.2 ~cormany/logs/f.3 … ~cormany/logs/f.100000 .

AIX, like other UNIX and Linux operating systems, has a set size for the number of command-line arguments and environment variables that can be used. To view the set size in AIX, use the command getconf . Per the man page for getconf , you should look at ARG_MAX :

#man getconf … ARG_MAX Maximum length, in bytes, of the arguments for one of the exec subroutines, including environment data. … #getconf ARG_MAX 1048576 Show more Show more icon

This value tells you that you have 1,048,576 bytes you can use for environment variables and command-line arguments to execute. It looks like you exceeded that. To resolve this issue, two options are available:

Increase the amount via smitty chgsys and change ARG/ENV list size in 4K byte blocks or via chdev . I do not recommend changing a system-wide parameter every time you run into this type of error out of convenience: This should be the last resort.

and change or via . I do not recommend changing a system-wide parameter every time you run into this type of error out of convenience: This should be the last resort. Rather than using the command rm with 100,000 arguments, which will fail miserably, the command find does a much better job of removing the files: #find ~cormany/logs –name “f.∗” –exec rm {} \; Show more Show more icon find command searches the directory for any files beginning with f. rather than placing the burden on the shell’s command line. The find command then executes rm on each file found, thus removing every file beginning with f.

Conclusion

After reading this article, you should have a better understanding of those common errors you may have come across and how to resolve the problem quickly. The errors may look simple, but when being introduced to UNIX, it is essential that you understand the basic errors before moving ahead. Good luck on your troubleshooting!