Back to Tylogix Home Page

iSeries to UNIX: First Contact

By Thibault Dambrine


The first time I heard of UNIX as part of the greater (then AS/400) picture was at a TUG meeting which took place at the Hockey Hall of Fame, on May 17, 1994. The speaker for that memorable occasion was Eugene Carthra, of IBM. At that time, it sounded more like fictional techno-spin than anything very concrete.

AS/400 has since evolved into iSeries and we all know, a lot has changed in this landscape.

As for many AS/400 professionals with long years invested nearly exclusively in the OS/400 operating system, I have grown curious about UNIX.

Recently, on top of my iSeries duties, I got a chance to work on a UNIX/Oracle client-server project. The primary aim of this article is to share my UNIX discovery experience, from the viewpoint of a long time iSeries programmer. This will be done in three parts:

In Part 1, factual, will describe how the UNIX operating system works, and compare each of its major components with its equivalent in the iSeries.

In Part 2, somewhat subjective, will relate my top-10 impressions when first starting to work on UNIX, all along giving some precise examples to convey my points.

Finally, Part 3 provides a list of basic commands that can help one navigate in UNIX.


In the beginning...

In March of 1999, nearly 3 years ago, I became a self-employed contractor, working on Y2K upgrades. Now on my own, I realized or perceived that I was suddenly more exposed to lack of knowledge in other platforms than the AS/400.

Recognizing that UNIX is probably closer to OS/400 than NT, I started a single UNIX course at the Southern Alberta Institute of Technology (SAIT), not knowing quite yet where it would lead me. To my surprise, this course was not taught on UNIX, as I had expected it to be. Rather, it was taught using Linux. Within a few weeks, I was hooked, and eventually took the full set of courses for the UNIX certificate.


UNIX? What is UNIX?

In the late 1960's, Ken Thompson at Bell Labs had developed a game, "Space Travel", on an old GE computer that was later ported to run on a spare PDP-7. This project gave Ken Thompson, Dennis Ritchie, and Rudd Canaday the experience needed to develop a new operating system for the PDP-7 based on a new file system they had designed. This new operating system was capable of supporting two simultaneous users and was nicknamed (UNICS) for UNiplexed Information and Computing System. Bell Labs granted financial support to this project, and with time the name UNICS evolved into UNIX.

In 1974, UNIX was re-written and became the first operating system written in C, the language created by Dennis Ritchie. This enabled the first port of UNIX outside of the DEC PDP world where it was born, to a 32-bit INTERDATA 8/32 minicomputer system. That year, The Computer Science Department at the University of California, Berkeley, began to use UNIX.

By Version 7, UNIX had developed and matured into a relatively stable operating system, which could run on several types of computers. At that time, a Department of Justice injunction forbade AT&T to sell software. AT&T made Unix available to universities as an academic tool for a low cost. It became very popular in university computer science departments. A major developer of the UNIX OS was one of these universities. In 1977 the first Berkeley Software Distribution (BSD) version of UNIX was released. Berkeley added virtual memory support, TCP/IP networking, vi, csh (C Shell), and more.

When deregulation hit and AT&T was split into different companies in 1982, the old regulatory restrictions were lifted and selling UNIX for a profit was allowed. The user community, universities especially, did not welcome this change. University of Berkeley's BSD then became a prominent UNIX player through its affiliation with Sun Microsystems, the leading proponent of the Berkeley UNIX. As a result of commercial pressure AT&T changed their licensing agreement which enabled many OEM's (e.g. Hewlett Packard's HP-UX) to write UNIX versions of their own without necessarily following all the standards or being obliged to share their innovations. Thus, the fragmentation of UNIX started.

In 1988, the standard for UNIX operating systems was formalized by the IEEE (Institute of Electrical and Electronics Engineers) under the name of "Portable Operating System Interface" (POSIX). POSIX, in particular, describes how to program operating systems so that they can be ported with greater ease to different hardware. The effect is that one can write the source code for an operating system in C and then compile on different compilers designed to work on each hardware model. All major UNIX systems, including Linux, adhere today to the POSIX standard. The United States government is the largest single organization procuring computer equipment in the world. It was an early adopter of the POSIX standard, giving it a lot of credibility.

In 1993, AT&T sold its UNIX business to Novell, who sold it to the Santa Cruz Operation two years later. In the meantime, the UNIX trademark had been passed to the X/Open consortium, which eventually merged to form The Open Group, who now owns the UNIX trademark.

This UNIX history perspective would not be complete without a word on Linux. In the early 1990's, Linus Torvalds, a Finnish undergraduate student, looked at a small UNIX hybrid called Minix and decided he could do better. In the fall of 1991, he released the source code for a freeware kernel called "Linux". While it is POSIX compatible, it is not technically a "UNIX" operating system, as its kernel was developed independently. Linux does not belong to The Open Group.

The evolution of the Linux OS is nothing short of surprising. In a mere ten years the Linux freeware project, with the contribution of thousands of programmers, has grown from undergraduate project to fully configured, professional grade operating system.

Any doubts about Linux's ability to handle a heavy load? At time of writing,, the number one search engine on the World Wide Web, uses web's largest index of web pages (over 2 billion), powered by the world's largest commercial Linux cluster - more than 10,000 servers. With this, it handles over 150 million searches per day.


Part 1: Unix and iSeries: How far and how close?

What I found out when crossing to the UNIX world is that in the end, a computer is a computer, and that in many ways, even if the methods are different, the goals are mostly the same.

On the surface, and also from acquired reputation, one could be tricked into thinking the OS/400 and the UNIX operating systems are at opposite ends of a very large spectrum. Upon closer examination, it appears the overall methods used by UNIX and OS/400 to achieve computing goals are surprisingly similar. In the architecture diagram below, you can clearly see how both operating systems use similar layering methods to segregate the hardware from the software.

UNIX Architecture, compared to the iSeries




Control Language Layer

Control Language (CL)



(Bourne Shell,
Korn Shell,
C Shell
other UNIX commands)

Similar to the CL language on the iSeries. All programs, on a UNIX system communicate with the hardware via the Kernel.

Note 1: UNIX shell script is interpreted, not compiled.

Note 2: Other programs, such as databases systems, will also communicate with the hardware via the UNIX Kernel.

Software to hardware Layer

iSeries Micro-code

UNIX Kernel

Sits above the computer's hardware. All programs, including the UNIX shells, interact with the kernel. Programs are insulated from the hardware by the kernel, thus making Unix programs relatively portable from one platform to another.


IBM iSeries hardware only

IBM pSeries (formerly RS 6000), Hewlett Packard, Sun Microsystems, Intel PC and more.


DB2/400 only

Oracle, DB2, MySQL, Sybase and more

Programming Languages

RPG, C, C++, Java and more

C, C++, Java and more

Character Code




Beyond the basic architecture similarities and differences of these two operating systems, three more differentiators stand out:



Part 2: First Impressions

In any situation where you try a new car, visit a new house, you get a few "first impressions" that will likely remain in your mind for a while. In the next few paragraphs, I will describe my first UNIX impressions. My aim is to convey what I saw, as a typical iSeries programmer, when first crossing the line. Here are 10 items that struck me in my first UNIX experience:

1) Upon first glance, my number one impression was that UNIX could be probably well described as "MS DOS on steroids". The command line behaves the same way and it seems to be just as friendly. UNIX can accommodate multiple layers of directories (directories within directories) but it has no convenient way to represent or print the directory structure (not even a DOS "tree" equivalent). I subsequently found a shell script that could do that on the Internet, which means it can be done. It's just not there for you to start with. One other common point with DOS, the Shell Script language (Korn Shell, Bourne Shell etc..) is interpreted, like a .bat type of DOS file.

2) UNIX commands have evolved from many sources and many authors. They do NOT follow any type of naming convention. This, for the OS/400 programmer, is something to get used to. It's hard to compare commands like "CRTCLPGM" - named after "CReaTe Control Language ProGraM" with "awk" named after "Aho, Weinberg, and Kernighan" - the three authors of the command. "awk", by the way, is a text manipulation command.

3) If you do become acquainted with UNIX or Linux, or any of the flavors in between, you will need to get used to refer to "man" pages. The man command (short for "manual"), coupled with the command you are curious about, delivers manual pages (often referred to as man pages) describing the use of the command. Most times, man pages are cryptic and seldom have more than minimum examples. There is no prompting with F4 key or any equivalent to OS/400 command prompting in UNIX. In a strange twist of fate, QSHELL, the UNIX style shell implemented on OS/400 has no F4 prompt key support and no "man" command either. Again, there will be more on this topic later in the article.

4) Speaking of no iSeries-style F4 prompting, when UNIX usually executes, without warning, exactly what you tell it to do. Expect no warnings if you are about to do something completely silly. Case in point: If you logon as root, the UNIX equivalent to the OS/400 QSECOFR profile, you can comfortably type the following instruction: rm -rf /* and hit enter.

With this order, using that profile, UNIX will proceed to wipe out your entire system, including the operating system without even as much as a burp or a thank you. For this reason, to protect yourself against dangerous experiments, it is best to use the root user profile sparingly.

This of course, is one man's opinion on command prompting. There are developers who find the iSeries operating system too talkative for its own good, and that less verbose is better.

5) vi is the most well known editors on UNIX. If you know vi, you can be sure you know at least one editor on just about any Unix machine you will ever get to work on, save your trusty iSeries, who has chosen not to implement it in QSHELL. Pronounced "vee-eye", vi is short for visual interface.

Working with three modes of operation: "command", "insert" and "line editor", vi has over 100 commands. Entire books have been written about vi. My experience is that it is rather confusing until you figure out which mode you are in. This is the type of editor you have to use regularly to get proficient. UNIX pros swear by it. They often say it is the most powerful text-based editor available. If you think there is power in simplicity, you may be tempted to argue differently. My number one vi tip: stay away from the arrow keys on the right side of the keyboard - they wont move your cursor!

6) Object authority or "file permission" in UNIX lingo, is something to both be aware of and get used to. I will go into some detail here because this is a key concept. Understanding how permissions work in UNIX is a necessity for every-day operations and it also gives a good indication of the style in which UNIX works.

Each file has 3 sets of "read/write/execute" flags attached to it, one for the owner, one for the group and one for the public. These 3 flags can be set to 0 or 1. To handle all this in the most economical way, each of the three authority groups are represented by the binary value of an octal number. This Octal number, (0 to 7) translated in binary, gives a combination of 3 binary digits. Clear as mud? You need to understand that clearly when you work with UNIX, as this is one concept you will deal with every day. If for example, you write a small test shell script to see what you can do, you will never be able to execute it unless you change the permissions (using the obviously named chmod command) to give yourself permission to execute the file.

A file, in UNIX can be anything from a flat file to a UNIX script. A UNIX script with an "x" in the "execute" permission flag position is deemed executable, even if not compiled (shell script is interpreted). Each file has 3 types of permissions (read, write or execute), for each of the three categories of users (individual users, groups of users or all users).

The 0 to 7 values are actually used as a shortcut to say their binary value. For example, the binary value of Octal 5 is "101". This translates in a permission value of "r-x" or "read, no write, execute". Octal 6 translates to binary "110" and thus the permission value of "rw-" or "read, write, no execute". The table below tells the whole story:

Octal Value

Binary Value


Directory Listing



no read, no write, no execute




no read, no write,    execute




no read,    write,    no execute




no read,    write,    execute




   read, no write, no execute




   read, no write,    execute




   read,    write, no execute




   read,    write,    execute



If a file for example has permission setting 777, it really has permission setting where the owner has rwx (read/write/execute), the group has rwx (read/write/execute) and the public has rwx (read/write/execute) permission. The permission flags look like rwxrwxrwx, listed at the right side of the file in a directory listing.

If a file has permission setting 764, the individual has rwx (read/write/execute), the group has rw- (read/write/no execute), and the public has r-- (read/no write/no execute). The permission flags look like rwxrw-r--, listed at the right side of the file in a directory listing.

You can see the permissions on the files in a directory by doing a ls l command.

There is more to read on UNIX permissions, but this is the base functionality. Coming from the iSeries environment, this method of determining authority or permissions, looks like a step backwards. It is however widely used and accepted by UNIX lovers the world over. There is no equivalent in UNIX to the notion of "object" in OS/400 sense. This may help understand this somewhat simple permission system.

7) One of the things you may have heard already about UNIX is that there is more than one standard for this operating system. You heard the truth. The main UNIX flavors of UNIX currently in the market place are Berkeley UNIX, AT&T Systems V Release 4 , SunOS/Solaris, XENIX, SCO and Linux.

The closest thing to a governing body that says, "This is UNIX" is the POSIX standard. It is now an accepted fact that to be commercially viable, a UNIX system, of any flavor, has to be POSIX compliant. That said, as long as this minimum is met, any company is free to invent or come up with a newer, better and stronger version. This is good and bad at the same time, for obvious reasons. It is good because there is freedom to innovate and change, it is bad because there is no strict standard, and thus incompatibilities do creep in. Perhaps the closest thing to a standard in UNIX available right now is the Linux kernel, which is standard across all distributions (Red Hat, SuSe etc.). It is also evolving faster than all other UNIX flavors and provide a lot more user friendly utilities than the traditional UNIX vendors.

8) You may have heard of the term UNIX "shell" before. "Shell" is a UNIX term for the interface between the user and the operating system. The shell is the layer of programming that interprets and executes the commands a user enters. As the outer layer of an operating system, a shell can be contrasted with the kernel, the operating system's inner most layer or core of services.

There are several UNIX shells. The main shells are Korn shell, C-shell and Bourne shell. Why so many? The shell, in UNIX, is more or less equivalent to the iSeries CL language. Just as there are many UNIX operating system manufacturers, the UNIX Shell has also evolved over time. S.R. Bourne wrote the original UNIX shell around 1975. His version, one of the most commonly available, is the "Bourne shell". Bill Joy, from the University of California in Berkeley, created the "C shell". David Korn, at AT&T, created the "Korn shell". Linux has something called the "Bourne Again shell", also known as "bash". Consistently, each new shell creator (or creators) have tried to build upon established bases to create a better shell. Note that the Linux bash (Bourne Again shell) is free, as opposed to the other shells.

9) Despite differences between UNIX releases, some things are similar. Upon delivery, most UNIX systems have a number of standard directories, which contain well-known utilities or contain operating system programs that will perform certain functions or services.

The diagram below gives a quick idea of what these are. Note that the "/" is the symbol for the root directory. If you do a "cd /", you are doing a "change directory to root". This directory, in UNIX, is the OS/400 equivalent to QSYS, where all libraries ultimately belong. Note also that the example below is a typical map, but not necessarily an exact one for all UNIX flavors.

On the iSeries, up until recently, we had only one level of library or directory: There was QSYS, and all the libraries within it. This has now changed with the addition of the IFS, the Integrated File System, which allows multiple levels of directories.




Root directory of the filesystem.


User utilities fundamental to both single-user and multi-user environments.


Programs and configuration files used during operating system bootstrap.


Default bootstrapping configuration files.


Device nodes.


System configuration files and scripts.


Default system configuration files.


Configuration files for mail transport agents such as sendmail.


named configuration files.


Scripts that are run daily, weekly, and monthly, via cron.


ppp (point-to-point) configuration .


Empty directory commonly used by system administrators as a temporary mount point.


Process file system


Home directory for the root account.


System programs and administration utilities fundamental to both single-user and multi-user environments.


Programs used in a standalone environment.


Temporary files, usually a memory-based filesystem (the contents of /tmp are usually NOT preserved across a system reboot).


The majority of user utilities and applications.


Multi-purpose log, temporary, transient, and spool files.

10) In the same league as knowing what is going on with the authorities or permissions, there is a function in UNIX called the cron. The crontab file is equivalent to what we would call the "job scheduler" utility in OS/400.

The crontab, you guessed it, is UNIX's version of a task scheduler. At first glance, it is very cryptic, but it can be interpreted with relative ease if you know what it is talking about. Be prepared, in UNIX, "Relatively cryptic but can be interpreted" is practically a way of life. This is how the entire operating system is built. Many UNIX programmers will tell you that this is where the power is. Like beer, this may be an acquired taste, popular but acquired.

Back to the topic. A crontab file can have any number of commands. It can only process one command per line. One more thing to remember, after the last command, you must have a blank line or the CRONTAB will not run.

What does a crontab line look like?

The way the schedule looks is very cryptic but it's really very simple. There are five fields to the schedule. They are noted in bold below:


Note 0 = Sunday

Also note that the ASTERISK (*) stands for a WILDCARD meaning it will match any value.

Example 1:

0 * * * * /etc/

Means literally "execute the script located at /etc/" whenever the clock is equal to 0 minutes on ANYDAY, ANY HOUR, ANY DAY-OF-MONTH, ANY DAY-OF-WEEK. So the script is set to run ONCE PER HOUR EXACTLY ON THE HOUR regardless of what day it is or what hour.

Example 2:

0 0 * * * /etc/

is a little more picky. This crontab runs again whenever the internal clock hits ZERO (0) Minutes, but instead of running once per minute it will only run once per day. WHY? Because we also set the HOUR to zero so BOTH the MINUTE and HOUR must be equal to zero before crontab will execute /etc/ So this example runs once per DAY at MIDNIGHT server time.

Example 3:

21 14 * * 2 /yellow/brick/road/wizard.exe

This example sets a crontab entry to run only on Tuesday at 2:21 PM. Note that this is written in military style time, i.e. 14:21.


A Shell Scripting Minute

Shell scripting in UNIX is the equivalent of CL programming on iSeries. It is part of the basic skill set necessary to effectively use a UNIX based system. The following examples are designed to give the reader a basic idea of three concepts that are key to the UNIX shell way of programming:

  1. UNIX, unlike OS/400 or even NT is case-sensitive.
  2. The UNIX shell scripting language uses a lot of pipes and directional operators to pass the output of one command to the input of the next. Think of it as having the *OUTFILE of your iSeries command piped directly into the command that follows without transiting via a physical file. (see Example 1)
  3. In UNIX, even the simplest commands can have many optional flags that alter the command's default behavior. When unsure about which flags to use, you can get UNIX's equivalent of OS/400's F4 by typing the man command ("man" stands for "manual") followed by the command name. "man" pages are typically cryptic and provide minimal explanation. Many times, I find myself looking for other sources of information, either on manuals or on the Internet, which has a lot to offer for budding UNIX shell programmers.

Example 1: Piping the results of pf into the command grep:

ps -ef | grep costing

"ps" is the UNIX equivalent to WRKACTJOB. This script command produces a list of active jobs using "ps -ef",(-ef represents two directives for "ps". The "e" tells "ps" to display information on every process and the "f" to display full information about the process). The output of "ps -ef" is piped into the "grep costing" command which will filter every line outputted by "ps -ef" except lines which contain the word "cost".

Example 2: Pick an option!

ls -ltra *.*

In this example, the meaning of the options attached to the command is:

-l lists files in long form, giving more details.

-t lists the contents in order of time saved, beginning with the most recent

-r lists the contents in reverse order

-a shows all files, including hidden files

The "ls" command in UNIX is similar to the "dir" command in DOS. It is both the simplest (nothing much to printing the contents of a directory) and most complicated (there are a total of 23 options for that command!) command in UNIX. When used all by itself, it only yields very basic information on the content of a directory. What I mean is that by just typing "ls", you will not know from the results, which entries are directories and which entries are files. You will also not know which are executable and which are the ones you have access to.


ISeries and QSHELL

Over the course of this article, I have mentioned QSHELL several times. This article would not be complete without a word on this remarkable iSeries development.

To be fully Java compliant, IBM needed to supply a JDK (Java Development Kit) on its iSeries Server that could run standard Java commands such as
java, javac or javadoc, the same way other systems could. Remember, Java was first developed by SUN, who also manufactures UNIX systems. OS/400 CL commands just would not do. The OS/400 Team resolved the problem by supplying a new "shell" on the iSeries, appropriately named QSHELL. In addition to being able to run UNIX style commands, QSHELL is also the access door to the iSeries IFS (Integrated File System).

If you have not yet explored the IFS on your system, I strongly encourage you to do so. It is easily accessible (use the iSeries command STRQSH) and you are there.

STRQSH will start a UNIX shell type of command session on your iSeries. You can think of it as a green-screen QCMD session, with a different set of commands. These commands, as it is, are mostly UNIX style commands. To see what commands are available, you have to do a directory listing (use ls /usr/bin) .

I have tried it myself, and have found it works fine. My experience is that QSHELL works in a standard UNIX fashion for most (but not all) commands. While there is no help or access to man pages in QSHELL, if you have access to the Internet, there is no shortage of documentation for UNIX commands (look for "UNIX man pages" in any search engine). Two other UNIX commands that are noted for their absence in QSHELL: "more" and "vi". There are thus no convenient file viewers (except "cat" which is not practical for larger files) or editors on the initial version of QSHELL. On its FAQ, IBM says:

For my initial shell scripts, I have typed my text file on a PC and FTPed it over to the iSeries to run.

Although QSHELL is not completely new, I have to admit it is new to me. It seems that quietly, UNIX has slipped-in through the back door of OS/400. If you are curious about UNIX, if you have no access to a "pure" UNIX machine, if you are reluctant to partition your PC to install a copy of Linux at home, this may be a good spot to get familiar with UNIX commands and the UNIX type of environment.



At some point, while writing this article, I had the following idea for a conclusion.

In the field of Biology, the first person to express a systematic presentation of evolution was Jean Baptiste de Lamarck (1774-1829) in 1809. Lamarck described his vision of evolution as "the inheritance of acquired characteristics." No kidding! It nearly sounds like "Object Oriented Programming"! In 1859, Charles Darwin (1809-1882) published "The Origin of Species" in which he coined the term "natural selection" to describe the process by which organisms with favorable variations survive.

If one could think of operating systems as actual living and evolving organisms, who would use innovation, research and marketing as food to grow, one could actually apply Lamarck's and Darwin's theories to the UNIX's and the OS/400's of the world.

If you think about it, you could say that Digital's CPM or Microsoft's Xenix for example have not evolved, or not evolved fast enough. From lack of support and/or lack of market, they eventually died.

By contrast, like the dog-like creature that in a few million years ago evolved into today's horse, DOS, fueled by Microsoft, mutated into Windows. The horse, user friendly, rather pretty and widely used, is also fragile. If it breaks a single leg, you have to put it down and start training a brand new horse.

The S/34 OS, fueled by IBM, became S/38 OS and then OS/400. I would compare it to the mammoth, which evolved into the elephant. Famous for its quiet stability, did evolve with time, but while doing so, it kept its general shape. The elephant is famous for its long memory of past events - a feature which compares well with OS/400's advanced system logging features.

UNIX, fueled by the rich intellectual grounds of AT&T's Bell Labs and Berkeley hit the market running right from the start. A living fossil, I would compare it to the crocodile. Long time survivor, it has kept a lot of its old proven concepts. Not pretty, not friendly, but it has stood the test of time. It will be there for a while yet. One more thing about the crocodile, like UNIX, it comes in several brands that look similar but have subtle differences, like the alligator and the caiman.

Looking back May 17, 1994, I now suspect Mr. Carthra was referring to PASE (Portable Application Solutions Environment) - an integrated solution to allow UNIX applications to run on AS/400. As far as I have seen, PASE was a good idea but it did not change anybody's life. Close but no cigar! Will the iSeries's ability to run Linux on a logical partition be different?

This all begs the question, which one of these operating systems will be the next survivor? Which one will be the next one to go extinct in the process of evolution?

Eventually, I decided that all this Darwin stuff would be a bit too deep for such a light-hearted piece. Here is my real conclusion to this article.

UNIX is not particularly hard to learn. It does however require a good road map if one needs to understand and/or investigate anything in this operating system. There is a large perceived cultural gap between it and OS/400. But perhaps it is caused more by what we do not know than by what we do know. Case in point: OS/400 and QSHELL now coexist quite comfortably on the same box.

The primary aim of this article was to share with fellow RPG/CL colleagues some of my own experiences as a new UNIX user. QSHELL is now part of the iSeries Operating System. iSeries now also supports Linux support also now offered on this computer, it might be a matter of time before you are exposed to some form of UNIX influence, without having to even leave the iSeries world.

Through my descriptions and examples in this article, I hope to have given you, iSeries programmers, a feel for what UNIX is like. Overall, it has a different look but in practical terms, it does many of the same things as OS/400. Of course, reading someone's impressions is a start, but it is no substitute for trying it your self. I encourage every iSeries programmer who read these words to fire up QSHELL, see what you can do with it, explore your system and see the possibilities. If you are interested in a more in-depth look at UNIX, buy a copy of Linux, install it on a spare PC, with this you can have your own risk-free UNIX training ground.


Part 3: UNIX, the essential commands

In this section, you will find the basic commands that will get you going in UNIX. If there was an 80/20 rule here, you could say that 80% of the time, you will use these few commands. At any rate, they are a good start and you can always learn more from there on.


Files & Directory Commands


list files and directories

ls -a

list all files and directories


make a directory

cd directory

change to named directory


change to home-directory

cd ~

change to home-directory

cd ..

change to parent directory


display the path of the current directory


Moving & Copying Files

cp file1 file2

copy file1 to file2

mv file1 file2

move or rename file1 to file2

rm file

remove a file

rmdir directory

remove a directory

cat file

display the contents of a file on the screen (standard output)

more file

display a file a page at a time

head file

display the first few lines of a file

tail file

display the last few lines of a file

grep 'keyword' file

search a file for keywords

wc file

count number of lines/words/characters in file


Redirection (useful to string commands in Shell script)

command > file

redirect standard output to a file

command >> file

append standard output to a file

command < file

redirect standard input from a file

command1 | command2

pipe the output of command1 to the input of command2

cat file1 file2 > file0

concatenate file1 and file2 to file0


sort data


list users currently logged in

a2ps -P printer textfile

print text file to named printer

lpr -P printer psfile

print postscript file to named printer

Wildcard & Help (applicable to most commands)


match any number of characters


match one character

man command

read the online manual page for a command

whatis command

brief description of a command

apropos keyword

match commands with keyword in their man pages




File System Security

ls -lag

list access rights for all files

chmod [options] file

change access rights for named file (the rwx flags)

chown [options] file

change user ownership

chgrp [options] file

change group ownership

command &

run command in background (like SBMJOB)


kill the job running in the foreground


suspend the job running in the foreground


Background the suspended job


list current jobs

fg %1

foreground job number 1

kill %1

kill job number 1


list current processes (like WRKACTJOB)

kill 26152

kill process number 26152

Special credits to for material used in this article. for crontab examples

Recommended Reading:

Credits: Proofreaders around the world, who prefer to remain anonymous and have made this article more interesting, more fun to read.


Back to Tylogix Home Page