0

I am trying to pass File1.txt ">" File2.txt as terminal arguments to my program in order to override the cat command. But for some reason, the program is not working. Although the argc is 4 in above defined case but still the condition in the program is not getting true. Here is the code:

int main(int argc, char *argv[])
{
int readbytes,fp;
char buf[1024];

if(argc==2)
{
    fp=open(argv[1],O_RDONLY);
    dup2(0,fp);
    close(fp);
    readbytes=read(STDIN_FILENO,buf,1024);
    write(STDOUT_FILENO,buf,readbytes);
}

if(argc==4)
{
    printf("inside4");
    fp=open(argv[1],O_RDONLY);

    dup2(fp,0);

    close(fp);

    fp=open(argv[3],O_WRONLY|O_CREAT|O_TRUNC,S_IRWXU);

    dup2(fp,1);

    close(fp);

    readbytes=read(STDIN_FILENO,buf,1024);

    //printf("%c",buf);

    write(STDOUT_FILENO,buf,readbytes);
}
return 0;
}

I couldn't find a solution to this issue so I leave it to experts now.What is the reason for this problem?

NOTE:

For some reason when I send ./prog File1.txt > File2.txt to program, argc==2 condition is selected, however argc is 4. Why is that?

Regards

William Pursell
  • 204,365
  • 48
  • 270
  • 300
Alfred
  • 1,543
  • 7
  • 33
  • 45

2 Answers2

5

This is likely being caused by how you are running your program. Typing

./myProg foo > bar

will instruct most shells to run myProg with argument foo and save whatever is printed to stdout in a file named bar. To pass foo, >, and bar as command line arguments, use

./myProg foo \> bar

or

./myProg 'foo' '>' 'bar'

Side note: Because piping output into a file using > is part of the shell, not a program like cat itself, you likely shouldn't have to worry about it. Just write to stdout and the shell will handle the rest.

Matt Kline
  • 10,149
  • 7
  • 50
  • 87
  • 1
    Generally, commandline applications that permit a specified output path do not directly use the > operator at all; instead they provide a `--output=` type argument. – mah Dec 10 '12 at 16:23
  • @Alfred `argc` is 2 for `./prog File1.txt > File2.txt`. The first argument is the path you used to launch the program (`./prog`), and the second argument is `File1.txt`. – Matt Kline Dec 10 '12 at 16:36
  • 1
    I'm not sure what could cause that. Perhaps an issue with your print statement could cause it. – Matt Kline Dec 10 '12 at 16:41
  • and Now my program is even working with ">". I don't know what is causing that. Any solution to this weird behavior of I don't know OS or Terminal – Alfred Dec 10 '12 at 16:47
  • Although this answer indicates that `> bar` instructs the shell to redirect standard output to `bar`, it does not state that the shell removes `>` and `bar` from the command line, so the final text passed to the program is `./myProg foo` (suitable separated into fields in argv). Since this question is asked from the viewpoint of somebody new to how shells process command lines and pass them to programs, it would be helpful to describe the steps explicitly. – Eric Postpischil Dec 10 '12 at 17:19
1

What do you mean by the condition in the program is not getting true? Are you saying that you don't see "inside4" printed to the terminal? There are a few things to consider. First, you do no error checking. We will have to assume that all of your open and dup2 calls succeed. I would expect that "inside4" is getting printed to the end of the output file. The reason for that is simply that printf does not actually write anything. It just stores the string "inside4" in a buffer, but that buffer is not written to the output until your program exits, and by that time the underlying file descriptor has been changed to the output file. The simplest fix is to append a newline to the output, and write printf( "inside4\n" ); In the normal setup, printing a newline causes the internal buffer to be flushed. You can also explicitly flush the buffer after calling printf by calling fflush.

William Pursell
  • 204,365
  • 48
  • 270
  • 300