If I know that input to my program will come from a file descriptor with a (non standard) ID, how do I read from it?
For example, if I need to read from a file descriptor with the ID of 3, how do I do it?
Also, is there an easy way to test this in BASH without having to create another program and piping?
This is what I've got so far:
char buffer[100];
FILE* fd = fdopen(3, "r");
fgets(buffer, sizeof buffer, fd);
sscanf(buffer, "%d", &whatever);
It compiles but gets a segmentation error when I run it. I looked at it in gdb and it gets stuck at the fgets, so I guess I'm doing something wrong? Possibly cause there's no end of file coming in on file descriptor 3 when I'm testing (again, would be nice if I could properly test this in BASH).
In bash, assuming your executable is "a.out", do
./a.out 3< testfile
to have testfile assigned to file descriptor 3
The same invocation works in bash, sh, zsh, ...
It does not work in csh, tcsh, ...
If you don't previously open it, there is no file with file descriptor 3. fdopen() fails and hence fd is NULL, resulting in a segmentation fault when trying fgets() on it.
Always check the return value of your function calls.
Related
I have this program:
#include <stdio.h>
int main() {
char buf[10];
puts("gimme input:");
fread(buf, 1, 10, stdin);
printf("got %s", buf);
}
When I run this and open another terminal I try to write to stdin:
echo "ASDFASDFASDF" > /proc/{pid}/0
ASDFSADFSADF gets printed on the terminal that is running my C program, but fread still doesn't return until I type in the actual terminal. It also does not print any of the text that I wrote to /proc/{pid}/0
Is there something else I have to do to programatically input text to stdin?
If stdin is a terminal, then writing something to stdin will write to the terminal. Reading from the terminal will read whatever is typed into the terminal, not what's written to the terminal. This is just how terminals work.
If you want a program to read from something other than a terminal, you have to direct that to happen. Or, if you want to use a virtual terminal that you can put information into it and have it be read out, you have to direct that to happen.
Probably the simplest solution is to create a pipe with mkpipe and have the program read from the pipe rather than a terminal.
When you execute the echo command output-ing to the File Descriptor 0 you're just sending text. If you check the file descriptor using ls -l probably it is pointing to an device TTY or PTY/PTS. If you check the FD type using lsof it will be tty. It means you need to interact with this FD such as TTY.
Basically you need to simulate the input to get the expected behavior.
You can do this by calling the kernel tool ioctl.tiocsti(). I added a python code into the following similar question: Writing to File descriptor 0 (STDIN) only affects terminal. Program doesn't read
I was working on an assignment where a program took a file descriptor as an argument (generally from the parent in an exec call) and read from a file and wrote to a file descriptor, and in my testing, I realized that the program would work from the command-line and not give an error if I used 0, 1 or 2 as the file descriptor. That made sense to me except that I could write to stdin and have it show on the screen.
Is there an explanation for this? I always thought there was some protection on stdin/stdout and you certainly can't fprintf to stdin or fgets from stdout.
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main()
{
char message[20];
read(STDOUT_FILENO, message, 20);
write(STDIN_FILENO, message, 20);
return 0;
}
Attempting to write on a file marked readonly or vice-versa would cause write and read to return -1, and fail. In this specific case, stdin and stdout are actually the same file. In essence, before your program executes (if you don't do any redirection) the shell goes:
if(!fork()){
<close all fd's>
int fd = open("/dev/tty1", O_RDWR);
dup(fd);
dup(fd);
execvp("name", argv);
}
So, stdin, out, and err are all duplicates of the same file descriptor, opened for reading and writing.
read(STDIN_FILENO, message, 20);
write(STDOUT_FILENO, message, 20);
Should work. Note - stdout my be a different place from stdin (even on the command line). You can feed output from another process as stdin into you process, or arrange the stdin/stdout to be files.
fprintf/fgets have a buffer - thus reducing the number of system calls.
Best guess - stdin points to where the input is coming from, your terminal and stdout points to where output should be going, your terminal. Since they both point to the same place they are interchangeable(in this case)?
If you run a program on UNIX
myapp < input > output
You can open /proc/{pid}/fd/1 and read from it, open /proc/{pid}/fd/0 and write to it and for example, copy output to input. (There is possibly a simpler way to do this, but I know it works)
You can do any manner of things which are plain confusing if you put your mind to it. ;)
It's very possible that file descriptors 0, 1, and 2 are all open for both reading and writing (and in fact that they all refer to the same underlying "open file description"), in which case what you're doing will work. But as far as I know, there's no guarantee, so it also might not work. I do believe POSIX somewhere specifies that if stderr is connected to the terminal when a program is invoked by the shell, it's supposed to be readable and writable, but I can't find the reference right off..
Generally, I would recommend against ever reading from stdout or stderr unless you're looking for a terminal to read a password from, and stdin has been redirected (not a tty). And I would recommend never writing to stdin - it's dangerous and you could end up clobbering a file the user did not expect to be written to!
I am writing a program in C that needs to read lines from a file. I am using fopen() for that purpose currently.
This works fine with my program.
./myProgram /path/to/file
However, I am having trouble reading inputs like this:
./myProgram - <<END
This
is
some
nameless
file
END
So I am guessing - is the nameless file that has the contents between the 2 END's, but my program will given an error related to file not found in that case, which means that fopen() returned a null pointer.
I am wondering what is going on here?
You are correct. According to fopen's man, fopen requires a const char* to open the file. If you are just passing your argv into fopen, "This is some nameless file" is not a file path, and so fopen won't be able to find your file.
If you want to read from the stdin, you can use fgets or any other reading function that takes a FILE *stream argument, to which you can pass the stdin file stream.
I was working on an assignment where a program took a file descriptor as an argument (generally from the parent in an exec call) and read from a file and wrote to a file descriptor, and in my testing, I realized that the program would work from the command-line and not give an error if I used 0, 1 or 2 as the file descriptor. That made sense to me except that I could write to stdin and have it show on the screen.
Is there an explanation for this? I always thought there was some protection on stdin/stdout and you certainly can't fprintf to stdin or fgets from stdout.
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main()
{
char message[20];
read(STDOUT_FILENO, message, 20);
write(STDIN_FILENO, message, 20);
return 0;
}
Attempting to write on a file marked readonly or vice-versa would cause write and read to return -1, and fail. In this specific case, stdin and stdout are actually the same file. In essence, before your program executes (if you don't do any redirection) the shell goes:
if(!fork()){
<close all fd's>
int fd = open("/dev/tty1", O_RDWR);
dup(fd);
dup(fd);
execvp("name", argv);
}
So, stdin, out, and err are all duplicates of the same file descriptor, opened for reading and writing.
read(STDIN_FILENO, message, 20);
write(STDOUT_FILENO, message, 20);
Should work. Note - stdout my be a different place from stdin (even on the command line). You can feed output from another process as stdin into you process, or arrange the stdin/stdout to be files.
fprintf/fgets have a buffer - thus reducing the number of system calls.
Best guess - stdin points to where the input is coming from, your terminal and stdout points to where output should be going, your terminal. Since they both point to the same place they are interchangeable(in this case)?
If you run a program on UNIX
myapp < input > output
You can open /proc/{pid}/fd/1 and read from it, open /proc/{pid}/fd/0 and write to it and for example, copy output to input. (There is possibly a simpler way to do this, but I know it works)
You can do any manner of things which are plain confusing if you put your mind to it. ;)
It's very possible that file descriptors 0, 1, and 2 are all open for both reading and writing (and in fact that they all refer to the same underlying "open file description"), in which case what you're doing will work. But as far as I know, there's no guarantee, so it also might not work. I do believe POSIX somewhere specifies that if stderr is connected to the terminal when a program is invoked by the shell, it's supposed to be readable and writable, but I can't find the reference right off..
Generally, I would recommend against ever reading from stdout or stderr unless you're looking for a terminal to read a password from, and stdin has been redirected (not a tty). And I would recommend never writing to stdin - it's dangerous and you could end up clobbering a file the user did not expect to be written to!
popen stores o/p of the specified command into a file. How can I get similar functionality but o/p into a variable (i.e. in a char*) ?
No, popen() does not store output into a file. It specifies a stream, which might represent to a file on disk but which might also be at e.g. a pipe or socket. Streams are more abstract than files.
To have a pipe, you would open the pipe using e.g. pipe() and then call fdopen() on the proper end of the resulting pipe.
I could not find anything that returns o/p in a variable. It kind of makes sense as some commands' o/p can be large so to make the behavior consistent, o/p is stored in the file. I actually ended up reading from file returned by popen.
Thanks for all the help.
you can replace STDOUT and STDERR for the launched command with a stream that you control
Do you want to run a unix command from a C program, and store the output?
If so, then the sequence is to call FILE* pipe = popen("wc -l filename", "r"); and then read from the FILE* pipe just as you would read from a file opened using fopen. That is, you use functions like fgets or fscanf to read the output, just as you would if the output of the command were in a file.