All in the Family - Unix Processes

It's time for a discussion of parents and children of the Unix variety. The subject may seem a bit esoteric, but there are times when an understanding may head off confusion. Of course, a discussion of the subject may bring on confusion, too. This discussion also takes us back to the idea of shells, which was brought up briefly in Tipsheet Vol. 1, No. 3.

Whenever a command is run in Unix, it is "spawned" as a new shell in a new process (with the exception of shell commands, such as "cd"). The new process is called the "child" of the process from whence it was spawned, which was the "parent." The child knows a lot about its parent's environment, but not everything, and once the child gets going, the parent is not able to affect the child's. The parent process knows nothing about the child's environment. When the child process ends (dies), everything it knew is forgotten. In most cases when the parent process dies, the child process also dies (or processes, if there were more than one). This may sound more like an afternoon soap opera than a computer system, but there are reasons for it. It does tend to keep things under control, though. Some examples are probably now in order. We'll stick with talking about the ksh since that is the default for all Bama users.

In Tipsheet Vol. 1, No. 3 we talked about customizing your own setup and having it take affect automatically when you log in. In the ksh we used two files, .profile and .kshrc, to get this done. In .profile we set environment variables using the syntax

VARIABLE=value export VARIABLE

and we mentioned a variety of these. This is the file that gets read when you login for the first time in any given session. This will become the parent process for any other processes you spawn. Since environment variables get passed from parent to child, all your commands will have the information they need to work correctly. One example is the printing command, "lp". When you print, you actually spawn a new process. This process obviously needs to know which printer you want to use and will get it from the environment variable LPDEST, unless you tell it otherwise in the command itself.

Once we are logged in, if we want to make changes to .profile and test them we have to rerun it in a special way. This was mentioned in Tipsheet Vol. 1, No. 3, but might make more sense now. If we execute the file, .profile, then we will have spawned a child process. The commands in .profile will get done in the child process, but when it is done and the child dies, everything the child knew will be forgotten. We'll be left with the original parent environment. That is why we ran .profile by typing

. ./.profile (dot space dot slash dot profile)

The leading "." makes the exception to the rule of spawning a new process. By doing this we were running .profile in the current process. When making modifications to .kshrc it was necessary to run it using the same syntax in order to make the changes take affect.

What about the other file, .kshrc? It was in this file that we put other setup information, such as alias commands. Well, .profile only gets read on login, but .kshrc gets read at the startup of every new shell, so in here is where you want to put information that is to be known to all shells, not just a login shell. This becomes very important for users in the X-windows environment. All the windows being run are children of the original login. If the window is a "telnet-like" window, such as xterm, then you generally want the same setup as the parent process. In other words, you probably would like to have all the same aliases available. If an alias is set in .profile it will be set for the parent process but not for the children, i.e. not in all the windows. In order for all the windows to have the same aliases, the aliases must be defined in .kshrc.

Since a child cannot change the parent environment, there is a technique that can be used to setup a completely different environment for temporary use, then quickly get back to your original setup. Simply start a new shell by typing ksh (or csh or bash, or any other shell you want to try), then change your environment any way you please. You can change your printer, your current directory, your aliases, whatever you choose. When you are done type "exit". You will be placed back in your original shell with your original setup. You've undone all your changes with that one final command.

Next is the issue about parents dying. Generally, when the parent process dies all its children die too. So, if you are running a job and you have put it in the background (so you can continue to do other work), that job will die when you log out. Tipsheet, Vol. 2, No. 5 talks about putting jobs in the background. There are a few programs we have that ignore the dying of the parent and continue on. The Unix version of Netscape is one such example. Normally, though, you must tell Unix that you want your process to continue to live. This is done through the "nohup" command, as in

nohup commandname &

where commandname is the command you want to run in the background.

Finally, extensive use of .kshrc has a trap waiting for the unknowing. Many of the commands that one might put in here are suitable for an interactive process but make no sense to a background process. Why should all other processes care about the ream of aliases you might setup? By putting these all into .kshrc you can slow down the execution of all your commands, since the whole file must be processed each time you run a command. The best thing to do is stop the processing of .kshrc if you are not in an interactive shell. Put these lines into .kshrc, after the commands that all shells should know, but before the ones that only make sense in an interactive shell. It will keep your work moving.

case $- in *i*);; *) return 0;; esac

© 1999, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.

January 25, 1999 Vol. 3 Index Back to Vol. 3, No. 2 Ahead to Vol. 3, No. 4		Search:

	E-mail Internet Access Software Assistance Computer Labs Software Licensing Web Publishing Calendaring Computer Security Unix Training

	All in the Family - Unix Processes It's time for a discussion of parents and children of the Unix variety. The subject may seem a bit esoteric, but there are times when an understanding may head off confusion. Of course, a discussion of the subject may bring on confusion, too. This discussion also takes us back to the idea of shells, which was brought up briefly in Tipsheet Vol. 1, No. 3. Whenever a command is run in Unix, it is "spawned" as a new shell in a new process (with the exception of shell commands, such as "cd"). The new process is called the "child" of the process from whence it was spawned, which was the "parent." The child knows a lot about its parent's environment, but not everything, and once the child gets going, the parent is not able to affect the child's. The parent process knows nothing about the child's environment. When the child process ends (dies), everything it knew is forgotten. In most cases when the parent process dies, the child process also dies (or processes, if there were more than one). This may sound more like an afternoon soap opera than a computer system, but there are reasons for it. It does tend to keep things under control, though. Some examples are probably now in order. We'll stick with talking about the ksh since that is the default for all Bama users. In Tipsheet Vol. 1, No. 3 we talked about customizing your own setup and having it take affect automatically when you log in. In the ksh we used two files, .profile and .kshrc, to get this done. In .profile we set environment variables using the syntax `VARIABLE=value export VARIABLE` and we mentioned a variety of these. This is the file that gets read when you login for the first time in any given session. This will become the parent process for any other processes you spawn. Since environment variables get passed from parent to child, all your commands will have the information they need to work correctly. One example is the printing command, "lp". When you print, you actually spawn a new process. This process obviously needs to know which printer you want to use and will get it from the environment variable LPDEST, unless you tell it otherwise in the command itself. Once we are logged in, if we want to make changes to .profile and test them we have to rerun it in a special way. This was mentioned in Tipsheet Vol. 1, No. 3, but might make more sense now. If we execute the file, .profile, then we will have spawned a child process. The commands in .profile will get done in the child process, but when it is done and the child dies, everything the child knew will be forgotten. We'll be left with the original parent environment. That is why we ran .profile by typing `. ./.profile` (dot space dot slash dot profile) The leading "." makes the exception to the rule of spawning a new process. By doing this we were running .profile in the current process. When making modifications to .kshrc it was necessary to run it using the same syntax in order to make the changes take affect. What about the other file, .kshrc? It was in this file that we put other setup information, such as alias commands. Well, .profile only gets read on login, but .kshrc gets read at the startup of every new shell, so in here is where you want to put information that is to be known to all shells, not just a login shell. This becomes very important for users in the X-windows environment. All the windows being run are children of the original login. If the window is a "telnet-like" window, such as xterm, then you generally want the same setup as the parent process. In other words, you probably would like to have all the same aliases available. If an alias is set in .profile it will be set for the parent process but not for the children, i.e. not in all the windows. In order for all the windows to have the same aliases, the aliases must be defined in .kshrc. Since a child cannot change the parent environment, there is a technique that can be used to setup a completely different environment for temporary use, then quickly get back to your original setup. Simply start a new shell by typing ksh (or csh or bash, or any other shell you want to try), then change your environment any way you please. You can change your printer, your current directory, your aliases, whatever you choose. When you are done type "exit". You will be placed back in your original shell with your original setup. You've undone all your changes with that one final command. Next is the issue about parents dying. Generally, when the parent process dies all its children die too. So, if you are running a job and you have put it in the background (so you can continue to do other work), that job will die when you log out. Tipsheet, Vol. 2, No. 5 talks about putting jobs in the background. There are a few programs we have that ignore the dying of the parent and continue on. The Unix version of Netscape is one such example. Normally, though, you must tell Unix that you want your process to continue to live. This is done through the "nohup" command, as in `nohup commandname &` where `commandname` is the command you want to run in the background. Finally, extensive use of .kshrc has a trap waiting for the unknowing. Many of the commands that one might put in here are suitable for an interactive process but make no sense to a background process. Why should all other processes care about the ream of aliases you might setup? By putting these all into .kshrc you can slow down the execution of all your commands, since the whole file must be processed each time you run a command. The best thing to do is stop the processing of .kshrc if you are not in an interactive shell. Put these lines into .kshrc, after the commands that all shells should know, but before the ones that only make sense in an interactive shell. It will keep your work moving. `case $- in i);; *) return 0;; esac` © 1999, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.
Copyright © 1998-2004 The University of Alabama \| Disclaimer \| Contact: Help.Desk@ua.edu