Avoid common errors in UNIX and Linux

Discover the most common errors in UNIX® and Linux®—and how to avoid them.

Adam Cormany, National Data Center Manager, Scientific Games Corporation

Adam Cormany is currently the manager of the National Data Center, but he has also been a UNIX systems engineer, a UNIX administrator, and operations manager for Scientific Games Corporation. Adam has worked extensively with AIX as well as in Solaris and Red Hat Linux administration for more than 10 years. He is an IBM eServer-Certified Specialist in pSeries AIX System Administration. In addition to administration, Adam has extensive knowledge of shell scripting in Bash, CSH, and KSH as well as programming in C, PHP, and Perl. You can reach him at acormany@yahoo.com.



14 July 2009

Also available in Chinese

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!


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.

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.

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 -lls: 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

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


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

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX, Linux
ArticleID=412917
ArticleTitle=Avoid common errors in UNIX and Linux
publish-date=07142009