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

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

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

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

1. Switch users to root:

   # su - root's Password:

   
   
2. 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)

   
   
3. Change the permissions of the file in question:

   # chmod 555 /bin/ksh.new

   
   
4. 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

   
   
5. Exit su, then return to the original user:

   # exit # id uid=5008(cormany) gid=330(atc) groups=110(sales),201(sshd)

   
   
6. Attempt to execute the script again:

   # ./foo This is a just a test

   
   

Voila! The problem has been solved!

Back to top

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

# bar
ksh: bar:  not found.

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

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.

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

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

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

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

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.

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

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

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

  
  

  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.

• 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.

Back to top

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

# ./bar
ksh: ./bar:  not found.

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

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

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

Back to top

./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.<number> and e.<number>. 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.

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

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.
• 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 {} \;

  
  

  The 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.

Back to top

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!

Resources

Learn

• getconf: Read IBM's man page for the getconf command.
  
  
• The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX? Visit the New to AIX and UNIX page to learn more.
  
  
• Browse the technology bookstore for books on this and other technical topics.
  
  

Discuss

• File permissions: Check out the developerWorks AIX forum for file permissions.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • IBM Support Assistant Forum
  • Performance Tools Forum
  • Virtualization Forum
  • More AIX and UNIX Forums
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• ./foo: 0403-006 Execute permission denied.
• ksh: bar: not found.
• ls: 0653-341 The file . does not exist.
• ./foo: /usr/bin/ls: 0403-027 The parameter list is too long.
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers