Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

hey

Name: Anonymous 2011-10-25 10:51

Hey /prog/. I am trying to access stdin and stdout of a child program. Here is what I did.

This works for stdin of child, I can access it and send strings from parent to child. however reverse does not work.

#include  <stdio.h>
#include  <string.h>
#include  <sys/types.h>

void  main(void){
     pid_t  pid;
     int    i;

     char str[40];
     int     fd1[2];
     int     fd2[2];
     pipe(fd1);
     pipe(fd2);

     pid = fork();

     if(pid == 0){

       dup2( fd1[1], 1 );
       close(fd1[0]);

       dup2( fd2[0], 0 );
       close(fd2[1]);
       execl("./c","c", 0);
     }
    

     close(fd1[1]);
     close(fd2[0]);

     FILE *out = fdopen (fd2[1], "w");
     FILE *inp = fdopen (fd1[0], "r");
    
     for(i=0; i<10; i++){
       fprintf(out, "hello%d\n", i);
       printf("sent\n");
       fscanf(inp, "%s", str);
       printf("cli:%s\n", str);
     }
     close(fd2[1]);
     close(fd1[0]);
}

and ./c is


#include <stdio.h>

void  main(){
  int i;
  char t[20];


  for(i=0; i<10; i++){
      scanf("%s", t);
      printf("!%s!\n", t);
  }
}

Name: Anonymous 2011-10-25 10:53

I am trying to access stdin and stdout of a child
Reported.

Name: Anonymous 2011-10-25 10:55

>>2
loled

Name: Anonymous 2011-10-25 11:05

damn, found the problem. Child must flush stdout after each fprintf.

I won't be able to modify child program. Is there any way to make pipes flush automatically?

Name: Anonymous 2011-10-25 11:11

>>4
Is there any way to make pipes flush automatically?
Give them a handjob.

Name: Anonymous 2011-10-25 11:12

I mean disabling a child process's stdout buffring from parent process.
setvbuf(stdout,NULL,_IOLBF,0);
works but If only it is executed from child program, which will be third party

Name: Anonymous 2011-10-25 11:16

>>1
scanf("%s", t); i see a buffer overflow waiting to happen.

Name: Anonymous 2011-10-25 11:18

>>7
this is a test program.

Name: Anonymous 2011-10-25 11:21

>>8
fixing errors in the test program stage is easier than debugging a megabyte of code much later.

Name: Anonymous 2011-10-25 11:24

>>9
This program will be used for evaluating students' assignments. I hope that they output something wrong and my program crashes, it will be their problem.

Name: Anonymous 2011-10-25 11:38

1)you should pipe things before forking
2)you dont pass any args to execl so expect a shitrstorm when
opening an fd
3)how did you manage to create such a mess in 30 lines?
4)you should really do your homework first

Name: Anonymous 2011-10-25 12:08

>>11
you should pipe things before forking
huh? pipe things between what?
you dont pass any args to execl so expect a shitrstorm when opening an fd
I pass the name of the program ("c") as first argument and nothing else. what is wrong with it?
how did you manage to create such a mess in 30 lines?
as I said, it is for learning purposes. I am not that familiar with pipes and fork. and I don't find my code that messed up. maybe it is you
you should really do your homework first
I am an assistant, not a student. I don't do homeworks, bitch.

Name: Anonymous 2011-10-25 12:14

and I am assuming this will be impossible since buffering is done at application level.

I guess I will just force them to put setvbuf(stdout,NULL,_IOLBF,0); on their code

Name: Anonymous 2011-10-25 12:15

>>12
assistant to whom?
or may i say what, FAILURE?
you should be ashamed of yourself

Name: Anonymous 2011-10-25 12:17

>>14
Why?

Name: Anonymous 2011-10-25 12:18

>>6
Yes with fcntl or ioctl or something like that... hmm let me dig out some code

My code was callng this in the parent's block after pid

191     /* set non-blockin on fd's that parent will read from */
192     for(i=1;i<4;i++) {
193     n = fcntl(parent[i],F_SETFL,O_NONBLOCK);

So its set from the parent's perspective, not the childs

Name: Anonymous 2011-10-25 12:39

>>15
why? causegofuckyourself

Name: Anonymous 2011-10-25 12:42

>>17
well, if that is all good bye. and please use sage next time when you have nothing to contribute and planning to be a bitch. especially when you are wrong.
>>16
thanks, I will try it tomorrow.

Name: Anonymous 2011-10-25 12:46

>>18
fuck i am off the stupidity in this place is astonishing

Name: Anonymous 2011-10-26 6:35

>>6
I mean disabling a child process's stdout buffring from parent process.

Damn, boy. This buffering is performed by the child. When you call `printf` there it puts results into a piece of malloc'd memory. OS is not involved, so you can't tell it to disable buffering from another process.

Name: Anonymous 2011-10-26 8:14

How much is it buffered?  Are you not getting anything until the child exits?

A possible solution,  which sounds ghastly is to have the parent look like a tty from the chld's point of view.  I think this would  make it line-buffered  (ie auto flush after \n).

see openpty()

Name: Anonymous 2011-10-26 9:10

>>16
nah, this enables or disables blocking. or am I mistaken?
>>20
:( well it is not that important. I will ask students to set their stdout buffers to null.
>>21
it just waits. Childs will be sending simple integers to server so it will be only a few bytes. It is buffered forever.

Weird thing \n does not the flush the buffer. It does while printing to console but not when it is a pipe.

Anyway it does not matter much. Asking students to insert setvbuf(stdout, NULL, _IOLBF, 0); to their code is not that much. Or maybe I can fix source files by hand

Name: Anonymous 2011-10-26 14:39

>>20

Damn, boy. This buffering is performed by the child. When you call `printf` there it puts results into a piece of malloc'd memory. OS is not involved, so you can't tell it to disable buffering from another process.

Holy shit are you a dumbass. First off, a call to printf() doesn't necessarily mean the results are put into a piece of malloc'd memory. The second thing, the OS is involved. Now perhaps instead of jerking off to SICP, perhaps you should actually purchase and read "Advanced Programming in the Unix Environment" by Stevens and Rago.

Name: Anonymous 2011-10-26 14:52

>child program
>cp

saged, reported, hidden, and contacted the local authorities

Name: Anonymous 2011-10-26 14:54

I hope to not find this thread still here tomorrow.

Name: Anonymous 2011-10-26 14:55

>>24
| >child program
| >cp
  Learn to quote, please~!

Name: Anonymous 2011-10-26 15:10

>>26
I
hope
you're
trolling.

Name: Anonymous 2011-10-26 15:52

>>22
Yes that's expected.. If it's a terminal it's line buffered.  With the pipe it's buffered into larger chunks (maybe 1024 or something),  because its not a tty.

If you appear as a tty to the child then it will line buffer there too.  Hence openpty etc.

Name: Anonymous 2011-10-26 17:39

An actual programming thread on /prog/?! WTF

Name: Anonymous 2011-10-26 17:40

>>28

Yes that's expected.. If it's a terminal it's line buffered

Again, you are a stupid fucker. And I quote pages 135 and 136 in "Advanced Programming in the Unix Environment" by Stevens and Rago.

"Line buffering is typically used on a stream when it refers to a terminal: standard input and standard output for example.

Line buffering comes with two caveats. First, the size of the buffer that the standard I/O library is using to collect each line is fixed, so I/O might take place if we fill the buffer before a newline. Second, whenever input is requested through the standard I/O library from either (a) an unbuffered stream or (b) a line-buffered stream."

Do you see anything that requires a terminal, when used as a predicate, to be true? Because I sure a hell don't.

Name: Anonymous 2011-10-26 18:16

>>29
and a multi "process" one:|

Name: Anonymous 2011-10-26 20:47

>>28
openpty
BUGS
       Nobody knows how much space should be reserved  for  name.   So,  calling  openpty()  or
       forkpty() with non-NULL name may not be secure.

C SUCKS DICKS. GC AND MANAGED/SAFE LANGUAGES ARE THE FUTURE.

Name: Anonymous 2011-10-26 21:43

The Dubz are after me.

Name: Anonymous 2011-10-26 22:29

>>30

It is mentioned in the word might. The common implementation of the standard IO library is to use line buffering when writing to a terminal, and wait-till-le-buffar-es-full buffering when writing to something that is not a terminal. If you would like to get a program that uses line buffering only when writing to a terminal, because it relies on a library with such behavior for its IO, then the only way to get it to do line buffering when not writing to a terminal is to fake it out into thinking it is writing to a terminal via a virtual terminal, although if it is open source you could modify what it uses for io, but this isn't practical in general.

Name: Anonymous 2011-10-26 23:02

>>32
Nobody knows how much space should be reserved  for  name.
It's obviously a pathname so it should be PATH_MAX+1.

Name: Anonymous 2011-10-27 19:01

>>34
It says generally you idiot.

The common implementation of the standard IO library is to use line buffering when writing to a terminal,

I can cite a few examples where the terminal isn't line buffered. Again, you are a total stupid shit.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -