This question already has answers here:
How can I pass the redirection operator '>' as an argument for execv?
(2 answers)
Closed 4 years ago.
I am trying to pass some arguments into an execv call:
char *const paramList[] = {"/bin/grep", "-rn", "comrade",
"/home/sgspectra/Documents/testing_grep/",
">>", "output.txt", NULL};
I believe that ">>" and "output.txt" are being read as arguments for additional directories to search through instead of to send the output to "output.txt". Is it possible to send an argument that would indicate only the previous argument is a directory?
When you type a command into a shell that supports >>, the shell handles the “>> filename’ in your command itself. Then it removes that text from the command line. The rest of the command line (the parts that were not removed, including your command and any other arguments), are then passed to execv or one of its related functions.
To do the same thing, what you need to do is something along the lines of:
Call fork to create a subprocess of your process.
In the parent (where fork returns a process ID for the child it created), go on with other execution—the parent might wait for the child or it might go on to do other things.
In the child (where fork returns 0), close file descriptor 1 (standard output) and use openat to open output.txt in append mode at file descriptor 1. Then call execv.
(Caveat emptor: It has been a few decades since I did things like this, so my memory may have changed, and the precise steps required may have changed.)
A cruder but easier-to-code option is to use execv to execute a shell, which you pass parameters requesting it to interpret and execute your command, including the redirection, as shown in this answer.
Related
I am writing my own shell in C. It's fairly simple, but I want to implement three more commands. First being commands, with or without arguments, whose output is redirected to a file. Second being, a command, with or without arguments, whose output is appended to a file. Lastly, a command, with or without arguments, whose input is redirected from a file.
All of these commands can be implemented using the syscalls freopen(), dup() and dup2().
An example of the first command could be ls -l > fileName.txt.
This should take the output of the command and put it in fileName.txt.
An example of the second command could be ls -l >> fileName.txt.
This should take the output of the command and append it to whatever is in the file fileName.txt.
An example of the last command could be bc < file. This takes the output of the command and put it in the named file.
This shouldn't be too hard to implement, but for some reason I don't know how to do it and am having some serious trouble. Could someone help me out?
I'd stick to raw system calls. Forget freopen() and use open(). The stdio routines work with FILE* streams while the syscalls work with integer file descriptors. Mixing the two guarantees serious trouble. ;-)
Redirection goes in 4 steps
open() file to redirect to/from, returns an fd
close() file to redirect, 0 for stdin, 1 for stdout
dup(fd) fd was returned by open() in the 1st step
close(fd) you don't need it enymore
The trick is that dup() returns the lowest available integer for a new file descriptor. If you've just closed stdout 1, it will return 1, and suddenly your stdout is pointing to the previously opened file.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Writing a shell - how to execute commands
I've been tasked with writing a shell in C. So far I understand that execvp will try to run the program in arg1 with arg2 as parameters. Now it seems that doing this
execvp ("ls", args); //assume args is {"ls", ">", "awd.txt"}
is not equivalent to typing this in the console
ls > awd.txt
I realize that I need to use freopen to achieve the same results but I'm curious what execvp is doing.
The exec family of functions are ultimately a system call. System calls go straight into the kernel and typically perform a very specific service that only the kernel can do.
Redirection, on the other hand, is a shell feature.
So, when one types ls > awd.txt at a shell, the shell first does a fork(2), then it closes standard output in the child, then it opens awd.txt on file descriptor one so that it's the new standard output.
Then, and only then, the shell will make an exec-family system call.
In your case you simply passed the strings > and awd.txt to the exec system call, and from there to ls. BTW, be sure you terminate your execvp arg array with a null pointer.
Note: As you can see, the redirection operators are never seen by the executed program. Before Unix, directing output to a file had to be done by every program based on an option. More trivia: most programs never know they were redirected, but ironically, ls does check to see if its output is a tty, and if so, it does the multi-column formatted output thing.
It's executing ls with 2 arguments: > and awd.txt. It is equivalent to running:
'ls' '>' 'awd.txt'
You can pass your command directly to the shell:
char * const args[] = { "sh", "-c", "ls > awd.txt", NULL};
execvp("/bin/sh", args);
But it doesn't seems like a good idea.
I use fork()/exec()/wait() rather than system() when the command has user input as some of its arguments so the user can't put something like...
&rm -rf /home/* && echo HAHA
... as an argument.
I'm assuming popen is as dangerous as system() because it takes a single string and not a list of strings like the exec family of functions do.
I can only get the return value from the exec functions though. Is there a "safe" version of popen that I can run with user input and process stdout / stderr back in the parent process?
The safe way is to set up the necessary pipes yourself, using straight pipe() calls directly.
That's what popen() does under the hood, but it also invokes the shell in order to run the child process. Skipping that step should make it safer.
I am trying to execute a program from within a C program (inside UNIX).
I have been given an executable ( the program requires a string input during execution and writes that input to another file called sample ) called exec and I want to execute it in program.c, but giving the string input through indirection.
For that I created a file as follows:
% vim input
I wrote the following inside the input file
content
Now in program.c,
#include<unistd.h>
int main()
{
const char* command = "./exec < input";
execvp(command, NULL);
return 0;
}
When I run the program, the content is not entered into the sample file.
But when I run it without indirection, i.e.
const char* command = "./exec";
then it works, and input entered in saved in sample file.
Can someone please tell what am I doing wrong in the indirection syntax.
Thanks.
The syntax you are using is supposed to be interpreted by a shell like bash, csh, ksh, etc.
The system call execvp only expects the path to the executable and a number of arguments, the shell is not invoked there.
To perform redirection in this manner, you'll have to use the dup2(2) system call before calling execvp:
int fd = open("input", O_RDONLY);
/* redirect standard input to the opened file */
dup2(fd, 0);
execvp("/path/to/exec", ...);
Of course, you'll need some additional error checking in a real-world program.
You can't do redirection like that with execvp. Use system() or start getting friendly with dup() and friends. You might google 'implementing redirection'.. you'll likely turn up plenty of examples of how shells (for example) handle this problem.
The exec(3) family of functions does not know anything about input redirection or parsing command lines: it tries to execute exactly the executable you give it. It's trying to search for an executable file with the name "./exec < input", which unsurprisingly does not exist.
One solution would be to use the system(3) function instead of exec. system invokes the user's shell (such as /bin/bash), which is capable of parsing the command line and doing appropriate redirections. But, system() is not as versatile as exec, so it may or may not be suitable for your needs.
The better solution is to do the input redirection yourself. What you need to do us use open(3) to open the file and dup2(3) to duplicate the file descriptor onto file descriptor 0 (standard input), and then exec the executable.
I have some problem to figure out how I can maintain the pipe and redirect functionality of a shell once I find out that there are missing command line arguments.
If I for example use a scanf call, that will work with a re-direct or a pipe from a shell, but in absence of this I get a prompt, which I don't want.
I would like to accept command line arguments through argv[], a pipe or re-direct but I can't figure out how to do it with out getting the prompt. If I for example try something like this:
if(argc < 2)
exit(0);
Then the program will terminate if I try this:
echo arg | myProgram
Or this:
myProgram < fileWithArgument
I have tried to look this up but I always get some bash scripting reference.
The common way to handle situations like this is to check if the standard input stream is connected to a terminal or not, using isatty or similar functions depending on your OS. If it is, you take parameters from the command line, if not (it's been redirected), you read standard input.
Short version: You can't do it.
Pipeline and redirect specifiers are not arguments to your program, rather they are commands to the invoking shell and are processed before the running instance of your program even exists. The shell does no pass them to the program in argv or any other variable, and you can not discover them in any reliable way.
Neil has given you the way to determine if you are connected to a terminal.
In your examples you are using pipe redirection, both echo arg | myProgram and myProgram < filesWithArguments are sending output to the STDIN of your program.
If you want to read these values, use scanf or fread on the STDIN file descriptor.
If you are trying to get the file content as an argument list for your executable, you need to use it like this:
# This will pass `lala` as a variable
myProgram `echo lala`