Controlling a child's stdin/stdout (not working with scp)
All,
Ok...so I know I *should* be able to control a process's stdin and stdout from the parent by creating pipes and then dup'ing them in the child. And, this works with all "normal" programs that I've tried. Unfortunately, I want to intercept the stdin/out of the scp application and it seems scp is actively refusing to allow me to. The code is:
I know the code works if I use something other than scp, I can write and read to the pipes all day long and control the process as desired. But, it seems that scp is specifically figuring out what the controlling terminal of the process is and actively refusing to co-operate with my pipes.
I then thought maybe I could try to "disown" the terminal by calling "setsid()" right before invoking scp (and tried it right after the fork). Well, that "works," but then the stupid thing connects to my X server and pops up a box to ask for the password. Of course, preventing scp from asking me anything is the exact reason I want to control the standard in of the process so I can funnel the password in through there.
So...does any one have another idea how I can redirect stdin/stdout for this most difficult process? It seems I'll actually need to "hook into" the terminal directly since scp is "so smart." Indeed, I believe scp may be openning up its own connection to the terminal to get input and send output....
Thanks....
P.S. I know there is a better way to do this, like creating the ssh keys so scp never asks for passwords to begin with. Unfortunately, the environment where I'm trying to use this disallows this. They want us to enter passwords every time and this "stupid" rule is circumventing my ability to automate tasks through scp; of course ftp is also taboo. So...I want this "scp wrapper" to read my local password file and just pass it through so I can get back to my regularly scheduled automation. Otherwise, I'll have to enter the passwords again and again while the scripts run...and that's just...well...pointless.
Hello all, I am trying to create n child processes and control them from a parent process; say make child 3 print its pid and then child 5 do the same and some other stuff. Is there a way to accomplishing this after all the child processes are created via a call to fork().
Thank you,
FG (23 Replies)
Hi,
Program A: uses pipe()
I am able to read the stdout of PROGAM B (stdout got through system() command) into PROGRAM A using:
* child
-> dup2(fd, STDOUT_FILENO);
-> execl("/path/PROGRAM B", "PROGRAM B", NULL);
* parent
-> char line;
-> read(fd, line, 100);
Question:... (2 Replies)
Hi all
I've run into a snag in a program of mine where part of what I entered in at the start of run-time, instead of the current value within printf() is being printed out.
After failing with fflush() and setbuf(), I tried the following approach
void BufferFlusher()
{
int in=0;... (9 Replies)
Hi,
i know how to
a) redirect stdout and stderr to one file,
b) and write to two files concurrently with same output using tee command
Now, i want to do both the above together.
I have a script and it should write both stdout and stderr in one file and also write the same content to... (8 Replies)
Hi,
I am working on a project where I have to generate and execute nasm code on-the-fly. I generate the code in a file program.asm and then execute it.This output is to stdout which i redirect to an output file which i read back to compare results:
system("nasm -f elf program.asm >... (5 Replies)
Hi,
i am using the below program to read from the standard input or to write to standard out put.
i know that using highlevel functions this can be done better than what i have done here.
i just want to know is there any other method by which i find the exact number of characters ( this... (3 Replies)
I am trying to implement the below using Ksh script on a Lx machine.
There is a file(input_file) with 100K records. For each of these records, certain script(process_rec) needs to be called with the record as input. Sequential processing is time-consuming and parallel processing would eat up... (2 Replies)
Well.. let's say i need to write a pretty simple script.
In my script i have 2 variables which can have value of 0 or 1.
$VERBOSE
$LOG
I need to implement these cases:
($VERBOSE = 0 && $LOG = 0) => ONLY ERROR output (STDERR to console && STDOUT to /dev/null)
($VERBOSE = 1... (5 Replies)
Discussion started by: Marmz
5 Replies
LEARN ABOUT REDHAT
stdin
STDIN(3) BSD Library Functions Manual STDIN(3)NAME
stdin, stdout, stderr -- standard I/O streams
SYNOPSIS
#include <stdio.h>
extern FILE *stdin;
extern FILE *stdout;
extern FILE *stderr;
DESCRIPTION
Under normal circumstances every Unix program has three streams opened for it when it starts up, one for input, one for output, and one for
printing diagnostic or error messages. These are typically attached to the user's terminal (see tty(4)) but might instead refer to files or
other devices, depending on what the parent process chose to set up. (See also the ``Redirection'' section of sh(1) .)
The input stream is referred to as ``standard input''; the output stream is referred to as ``standard output''; and the error stream is
referred to as ``standard error''. These terms are abbreviated to form the symbols used to refer to these files, namely stdin, stdout, and
stderr.
Each of these symbols is a stdio(3) macro of type pointer to FILE, and can be used with functions like fprintf(3) or fread(3).
Since FILEs are a buffering wrapper around Unix file descriptors, the same underlying files may also be accessed using the raw Unix file
interface, that is, the functions like read(2) and lseek(2). The integer file descriptors associated with the streams stdin, stdout, and
stderr are 0, 1, and 2, respectively. The preprocessor symbols STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO are defined with these values
in <unistd.h>.
Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (For the masochistic
among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work.) A general rule is that file descriptors
are handled in the kernel, while stdio is just a library. This means for example, that after an exec, the child inherits all open file
descriptors, but all old streams have become inaccessible.
Since the symbols stdin, stdout, and stderr are specified to be macros, assigning to them is non-portable. The standard streams can be made
to refer to different files with help of the library function freopen(3), specially introduced to make it possible to reassign stdin, stdout,
and stderr. The standard streams are closed by a call to exit(3) and by normal program termination.
SEE ALSO sh(1), csh(1), open(2), fopen(3), stdio(3)CONSIDERATIONS
The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until
fflush(3) or exit(3) is called, or a newline is printed. This can produce unexpected results, especially with debugging output. The buffer-
ing mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call. Note that in case stdin is
associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (Indeed, nor-
mally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcsetattr(3); see also
stty(1), and termios(3).
CONFORMING TO
The stdin, stdout, and stderr macros conform to ANSI X3.159-1989 (``ANSI C89''), and this standard also stipulates that these three streams
shall be open at program startup.
Linux 2.0 March 24, 1998 Linux 2.0