prnott@phoenix.Princeton.EDU (Prabhu R Nott) (02/12/89)
I hope this is the right news-group for this question - Could someone tell me how I can redirect output from standard error to a file or device? In the Bourne shell, this can be achieved by command 2>filename, but this doesn't work in the C shell. Does anyone know what the syntax is? Thanks in advance. Prabhu.
mjg@rtmvax.UUCP (Mike Gogulski) (02/13/89)
In article <6295@phoenix.Princeton.EDU> prnott@phoenix.Princeton.EDU () writes: > > I hope this is the right news-group for this question - >Could someone tell me how I can redirect output from standard error >to a file or device? In the Bourne shell, this can be achieved by > > command 2>filename, but this doesn't work in the C shell. > >Does anyone know what the syntax is? Thanks in advance. > >Prabhu. Well, the syntax is is pretty simple. You can direct the stdout with the following: % command > file You redirect the standard error in the same way. % command >& file <-- this puts BOTH the stderr and the stdout into 'file.' These work with >> and >>& as well, for 'append to file.' However, there is no easy way in csh to duplicate th effects of the following sh command: $ command 1>stdout 2>stderr, because csh does either the stdout or both the stdout and the stderr. If you want to put the stdout in one file and the stderr in another, the way to go is something like this: % ( command > stdout ) >& stderr This, however, is kinda yucky. You might wish to look at Bob Glickstein's "redir" program, recently posted to comp.sources.misc, which allows redirection much like sh does. --Mike +-----------------------------------------------------------------------------+ | DISCLAIMER: | Mike ...{uiucuxc|petsd}!peora!ucf-cs!ucfunix!mjg| | I Am _NOT_ The Walrus | Gogulski ...{uiucuxc|petsd}!peora!rtmvax!mjg | +-----------------------------------------------------------------------------+ | "The number of UNIX installations has grown to 10, with more expected." | | (The _UNIX Programmer's Manual_, 2nd Edition, June, 1972.) | +-----------------------------------------------------------------------------+
eirik@lurch.Stanford.EDU (Eirik Fuller) (02/14/89)
In article <2904@rtmvax.UUCP>, mjg@rtmvax (Mike Gogulski) writes: > ... [discussion of redirection of stderr] >% ( command > stdout ) >& stderr > >This, however, is kinda yucky. You might wish to look at Bob >Glickstein's "redir" program, recently posted to comp.sources.misc, >which allows redirection much like sh does. Tell me, why not just do something like the following? sh -c 'command >stdout 2>stderr' In fact, my first reaction to the redir program was that it could have been a sh script ... I frequently find myself coping with csh annoyances by wrapping my command line with sh -c '[cmdline goes here]'. I tend to do loops as sh -c 'for f in *; do whatever; done' because I never did like foreach.
root@libove.UUCP (Jay M. Libove) (02/15/89)
From article <6295@phoenix.Princeton.EDU>, by prnott@phoenix.Princeton.EDU (Prabhu R Nott): > > I hope this is the right news-group for this question - > Could someone tell me how I can redirect output from standard error > to a file or device? In the Bourne shell, this can be achieved by > command 2>filename, but this doesn't work in the C shell. > Does anyone know what the syntax is? Thanks in advance. No doubt this should be in the Frequently Asked Questions section of the usenet introduction documents... The C shell lacks the ability of the Bourne shell to in one simply command redirect two types of output to two different places, but it provides it in a grosser (word?) way: c-shell% (command > stdout.file) >& stderr.file So that all standard output goes to stdout.file, and error output goes outside of the subshell in which command was executed, and is caught by forcing all output making out of that shell in to stderr.file. -- Jay Libove jl42@andrew.cmu.edu, libove@cs.cmu.edu, 5731 Centre Ave, Apt 3 gateway.sei.cmu.edu!libove!libove, jl42@andrew.BITnet, Pittsburgh, PA 15206 jl42@drycas.BITnet, psuvax1!pitt!darth!libove!libove, (412) 362-8983 or uunet!nfsun!libove!libove
dberg@cod.NOSC.MIL (David I. Berg) (02/15/89)
In article <6295@phoenix.Princeton.EDU>, prnott@phoenix.Princeton.EDU (Prabhu R Nott) writes: > > Could someone tell me how I can redirect output from standard error > to a file or device? command >& filename. -- David I. Berg (dberg@nosc.mil) GENISYS Information Systems, Inc., 4250 Pacific Hwy #118, San Diego, CA 92110 MILNET: dberg@nosc.mil UUCP: {akgua decvax dcdwest ucbvax}!sdcsvax!noscvax!dberg
ryach@sedona (09/23/89)
I am posting this question for a friend. Does anyone know if it is possible for a process to figure out if it is running in the background vs. interactive? All the "experts" at this site do not know. If you have a way, please respond to rpaul@sedona.intel.com thx --- : __ Randy L. Yach : /__/ __ __ __/ / / __ __ /__ Intel Corporation : / \_/__/_/ /_/__/_/__/ \_/_/__/_/___/ / ryach@sedona.intel.com : / /
bph@buengc.BU.EDU (Blair P. Houghton) (09/23/89)
In article <233@cmdfs2.intel.com> rpaul@sedona () writes: > >I am posting this question for a friend. Does anyone know if it is possible >for a process to figure out if it is running in the background vs. >interactive? All the "experts" at this site do not know. If you have a way, >please respond to Background and foreground are concepts related to the shell, not the process, and not intrinsically to the unix OS. I.e., the shell is the _only_ one that "knows" the interactiveness of a job. You have to get the program to "ask" the shell. Any job put in the background has an entry in the 'jobs' listing; so you'd think you could just match the process' pid with one in the jobs-list. The problem is in trying to communicate with the shell, which is the _parent_ of the process with the question. Job tables aren't environment variables, and aren't exported. You'd have to bust into the memory space of the ppid process to get at it, provided you aren't a process fork()'ed some levels deep in fork()'s (although a carefully designed program would preserve the ppid of the process that ran the top-level program). The only way (I can think of) is to try some I/O, and catch the SIGTSTP (SIGSTOP?) that the shell will raise (unless of course you've done 'stty -tostop'... but doing a read from the console will certainly make the shell try to stop the process). Perhaps you could do some sort of hack to bg/fg involving aliasing and setting of environment variables related to the pid of a backgrounded process... Not complete enough: It won't be able to handle processes backgrounded by the ampersand (&) on the command-line. Maybe ksh can do it better. --Blair "Say hi to marco, and tell him I'm about to wipe his tar's from my disks."
guy@auspex.auspex.com (Guy Harris) (09/24/89)
>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?