|
Home > Archive > Unix Programming > May 2005 > C pipe error
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Enos Meroka 2005-05-20, 2:48 am |
| Hallo,
Am using pipes in my C code to talk to a child process that I have
forked. However, I keep on getting an certain erro messge that I cannot
understand. My error is as below
========================================
========================
<Can't set terminal configuration (fd #0)>
<TCSETA>: I/O error
========================================
========================
could anyone help me in diagnosing the problem and possibly suggest a
suitable solution.
I have attached my code below
========================================
===========================
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void)
{
int result1, result2;
int parentfd[2],childfd[2],nbytes;
pid_t childpid;
char string[] = "Connecting..........!\n";
char string2[] = "Am Connected!\n";
char readbuffer[80];
pipe(parentfd);
pipe(childfd);
if((childpid = fork()) == -1)
{
perror("fork");
exit(1);
}
if(childpid == 0)
{
/* Child process closes up output side of pipe */
close(parentfd[1]);
close(childfd[0]);
/* Read in a string from the pipe */
nbytes = read(parentfd[0], readbuffer,
sizeof(readbuffer));
printf("\nChild Received string: %s", readbuffer);
/* Send "string" through the output side of pipe */
write(childfd[1], string2, (strlen(string)+1));
result1 = dup(parentfd[0]);
printf("\nValue returned by dup %d",result1);
printf("\nInvoking a process");
result1 = execlp("/usr/sbin/padem", "0302" , NULL);
printf("\nValue returned by execlp() %d",result1);
exit(0);
}
else
{
/* Parent process closes up input side of pipe */
close(parentfd[0]);
close(childfd[1]);
/* Send "string" through the output side of pipe */
write(parentfd[1], string, (strlen(string)+1));
/* Read in a string from the pipe */
nbytes = read(childfd[0], readbuffer,
sizeof(readbuffer));
printf("\nParent Received string: %s", readbuffer);
}
return(0);
}
========================================
===========================
| |
| vishal 2005-05-20, 2:48 am |
| I don't think it's a problem with your pipes as such.. what is this
`padem` program and can you verify if you get the same error even when
you don't call `padem`. I tried your code in linux, freebsd and tru64,
I didn't get any errors.
vishal
| |
| Enos Meroka 2005-05-20, 7:55 am |
| Thanks for your response.
padem is a PAD EMULATOR in my hp-ux system that allows me to telnet to
a remote system..
So am trying to actual create a session with this emulator called
padem. Something similar like creating a telnet session in a C program.
| |
| phil_gg04@treefic.com 2005-05-20, 7:55 am |
| > <Can't set terminal configuration (fd #0)>
I think that your "padem" program is unhappy because its stdin/stdout
are not connected to a terminal, but instead to a pipe. I suggest
running strace -f and looking at what padem does immeidately before the
error. I bet that it is doing an ioctl() or something similar that is
not supported on the pipe.
If this is true, you might consider using forkpty() instead of pipe()
and fork().
--Phil.
| |
| Rainer Temme 2005-05-20, 7:55 am |
| Enos Meroka wrote:
> Hallo,
> Am using pipes in my C code to talk to a child process that I have
> forked. However, I keep on getting an certain erro messge that I cannot
> understand. My error is as below
> ========================================
========================
> <Can't set terminal configuration (fd #0)>
> <TCSETA>: I/O error
> ========================================
========================
>
> could anyone help me in diagnosing the problem and possibly suggest a
> suitable solution.
Hi Enos,
as far as I can see, there is nothing wrong with your code ...
the error obviously comes from something completely different ...
There are programs in this world (like editors etc.) that wants
to be connected to something looking and feeling
like a terminal ... also the program only gets it's stdin/stdout
connected to this terminal, it can use ioctl() with a termios-
structure and the parameters TCGETA / TCSETA to get/set
terminal-settings ...
Obviously the pipes htat you used to connect to your childprogram
do not support these terminal-speccific ioctl()s ... and that is
the reason why the forked program is complaining .
If there is no command-line option to tell the program to
disregard the fact, that it's not connected to a terminal, then
you have only one option:
-> Give your program a terminal!
To do this, you use something different than pipes ... you
use a thing called a pseudo-tty (yes indeed, this already sounds like
a terminal) ... the setup of a pseudo-terminal is unfortunately
a bit more difficult than opening pipes ... If you google for
pseudo-tty you will quite likely find something helpful.
I'll only give you a very brief descriptnion of what to do:
Before fork() do the following:
masterfd=open("/dev/ptmx",RDWR)
(this is the Master-Side-Multiplexer of the
pseudos)
grantpt(masterfd)
unlockpt(masterfd)
now fork()
in the child do
ptr = ptsname(masterfd)
(this gives you the name of the associated slave-side)
slavefd=open(ptr,RDWR)
close(masterfd)
dup2(slavefd,0) dup2(slavefd,1); dup2(slavefd,2)
close(slavefd)
(this connects stdin/out/err to the slave-side)
exec( whatever you want to exec )
in the master do
read(masterfd,...) and write(masterfd,...)
write(master,...) will send data to the program you execed
read(master,...) will read data that was being sent by the program.
That's it.
Good luck ... Rainer
| |
| phil_gg04@treefic.com 2005-05-20, 7:55 am |
| > a pseudo-terminal is unfortunately
> a bit more difficult than opening pipes
If your library supports forkpty(), it becomes quite simple. But it is
still a good idea to understand what is going on underneath.
--Phil.
| |
| Rainer Temme 2005-05-20, 6:03 pm |
| phil_gg04@treefic.com wrote:
>
>
> If your library supports forkpty(), it becomes quite simple. But it is
> still a good idea to understand what is going on underneath.
>
> --Phil.
>
oh come on Phil ...
every "real programmer" has to produce a certain amount
of _special_ code-modules in his(her) life ...
-> a doubly-linked list
(just for the fun of handling this strange
next->previous=previous->next stuff.)
-> an implementation of qsort
(to check if your's i faster than the library implementation)
-> a clever replacement for malloc()/free() that checks
if verything is still in order.
(you simply cannt live without it)
...
and of corse a module handling pseudo-tty's ;-)
(just for the fun of doing it)
Regards ... Rainer
| |
| phil_gg04@treefic.com 2005-05-20, 6:03 pm |
| > oh come on Phil ...
> every "real programmer" has to produce a certain amount
> of _special_ code-modules in his(her) life ...
>
> -> a clever replacement for malloc()/free() that checks
Strangely enough, just yesterday was was writing my own memory
allocation functions.....
--Phil.
|
|
|
|
|