Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: C shell question Message-ID: <2491@auspex.auspex.com> Date: 24 Sep 89 00:09:41 GMT References: <233@cmdfs2.intel.com> <4331@buengc.BU.EDU> Reply-To: guy@auspex.auspex.com (Guy Harris) Distribution: usa Organization: Auspex Systems, Santa Clara Lines: 46 >Background and foreground are concepts related to the shell, not the >process, and not intrinsically to the unix OS. Definitely true on systems that don't support job control or with shells that don't on systems that due. Not really true on systems supporting job control, but.... >Not complete enough: It won't be able to handle processes backgrounded >by the ampersand (&) on the command-line. Well, in the job control shells with which I'm familiar, jobs backgrounded with "&" are like jobs backgrounded by stopping them and doing "bg". >Maybe ksh can do it better. Probably not. While there are ways a program on a system with job control can find out if it's in the background in the job-control sense, the problem is that the answer to the question "am I in the background" is subject to change over time in a system with job control! I.e., just because the process was in the foreground or background at the time the it checked whether it was in the foreground or in the background doesn't mean it's still there at the time the program actually uses this information. In other words, if you think you want to make your program check whether it's in the foreground or background, and have it act differently in those circumstances, think harder - your scheme may not work if somebody moves the job running your program between the foreground and background. By and large, most UNIX programs get along quite well without bothering to find out whether they're running in the foreground or in the background. Some programs *might* want to check e.g. whether they're getting their command input from a terminal or not, as a way to see if they're being run "interactively" or in "batch" mode, but that's a different check entirely - yes, in a system with job control, a job in the background can be getting its input not only from *a* terminal, but from the user's terminal - if they try to read from that terminal, they'll be stopped, but the user can then move them to the foreground and type at them. If you *really* are trying to find out if your program is being run "interactively" or in "batch" mode, consider checking whether the standard input is a terminal, or using a command-line flag, or something like that. A question for Steve Hayman: is this another candidate for the "frequently asked questions" list?