Thread: Execvp help

Why do you open this file at all? You never read from it. You do not need to open the file to call sort on it.

Anyway, AFAICT you can't get exec to work this way:

Code:

execlp("sort","sort","file.1",">","file.2" NULL);
execlp("sort","sort file.1 > file.2" NULL);
execlp("sort","sort","file.1","> file.2" NULL);

None of these will work. You have to use system() instead.

Originally Posted by hambergler

Ok I changed it a bit, but now I'm having trouble getting the file name into the system call... here's what I did:

[code]

char command;

/*attempt to get the file name stored in *argv to append to the sort command*/
command = strcat("Sort ",argv[1]);

"char command" is one character. Use "char command[1024]" or something.

You don't have to use fork() with system. You need it with exec() because exec causes the current process to be replaced (notice, no code after an exec() call gets executed). This is not an issue with system().

So if this is for an assignment that's supposed to teach you about fork and exec, then choose a different task (if not, just use system with no fork).

WRT argv[1], the argv array is broken on whitespace unless you use quotes. So eg, if your executable is called a.out:

./a.out do > this
argv[1] will be "do", argv[2] will be ">", argv[3] will be "this".
./a.out "do > this"
argv[1] will be "do > this".

Originally Posted by hambergler

This is for a project. I'm learning to close a "line" like stdout or stdin and open another file to connect to the closed line. Thus the fork and the previous execlp. I'm just having trouble with the syntax of the exec family.

Okay -- well, you have hit a limitation of exec/execlp. Someone may come along with evidence to the contrary, but I am pretty sure this kind of command:

sort somefile > someotherfile

or anything else involving > redirection is not possible. You can't even use pipes (|) with exec. You can really only issue one single command, and provide values for the arguments it accepts. "> somewhere" and "| whatever" are not arguments to the command. They're part of the shell's own I/O functionality. You may be able to pull it off by opening a file and using dup() and pipe() -- but honestly, I would not bother. This is not what is expected of you. You just need to issue a simple command with optional arguments.

Not sure what you're looking for, but this should work :

Code:

char in_file[] = "input_file.txt"

execlp("sort","sort", in_file, NULL);

You'll also have better luck if you search for pipes by their correct term - pipes. For example, Mapping UNIX pipe descriptors to stdin and stdout in C.

Also, to clear up what Mk27 said about command line parsing - " >" and "this" don't show up as command line arguments because they're not. The shell strips them off and uses them to figure out how to redirect stdin/stdout. For instance

./a.out 1 2 3
and
./a.out 1 2 3 > foo.txt

both get the same command line arguments passed to them. The only difference is where stdout goes.

You can replicate what the shell is doing using the pipe() or open() and dup() functions. There are bazillions of tutorials on the web - this is pretty basic Unis stuff so everyone's had to do it for homework before.

Anyway, I think there's some confusion on exactly what you're trying to accomplish. How about posting a high level view of what you're trying to do instead of thinking you must use fork/exec and so on?

Originally Posted by KCfromNC

Also, what Mk27 said about command line parsing is wrong.

Incorrect how?

" >" and "this" don't show up as command line arguments because they're not. The shell strips them off and uses them to figure out how to redirect stdin/stdout.

Ah, I said as much* -- but further: that does not happen via exec(). Try it. Instead, the command is fed all that as parameters (and chokes, or ignores them).

./a.out 1 2 3
and
./a.out 1 2 3 > foo.txt

both get the same command line arguments passed to them. The only difference is where stdout goes.

Right, you, I, and the OP already understand this part. The problem is you cannot issue the 2nd command effectively inside an exec(). You would have to set up redirection for the process yourself first.

* QUOTE: "> somewhere" and "| whatever" are not arguments to the command. They're part of the shell's own I/O functionality.

> fd = creat("userlist", 0644);
> execlp("sort","sort",in_File,">", "userlist" , NULL);
As already pointed out, exec functions do not do redirections.

What you need to do here is

Code:

		close(1);  // close stdout
		fd = creat("userlist", 0644);  // creat will use the lowest available fd (in this case, 1)
		execlp("sort","sort",in_File, NULL);  // sort the in_File, writing to the 'new' stdout

Cool. This works too, it was what I was thinking of earlier, but Salem's solution is much simpler:

Code:

#include <stdio.h>
#include <unistd.h>

int main(int argc, const char *argv[]) {
	FILE *in, *out;
	int pipes[2];
	char buf[256];
	pid_t pid;

	if (argc < 2) return 0;
	if (pipe(pipes)) return 0;

	pid = fork();
	if (!pid) {
		close(pipes[0]);
		dup2(pipes[1],1);
		close(pipes[1]);
		execlp("sort","sort",argv[1],NULL);
	} else {
		out = fopen("out.txt", "w");
		close(pipes[1]);
		in = fdopen(pipes[0], "r");
		while(fgets(buf,256,in)) fprintf(out,"%s", buf);
		fclose(in);
		fclose(out);
	}

	return 0;
}

Originally Posted by KCfromNC

We posted at the same time so I was talking about your earlier response -

./a.out do > this
argv[1] will be "do", argv[2] will be ">", argv[3] will be "this".

Oh yeah, that would be wrong wouldn't it Sorry.

Originally Posted by cas

I'd just like to point out that you should not pass NULL to execvp(), but (char *)NULL. This matters on systems where NULL is 0 (thus an int), but pointers are not the same size as an int (or when 0 and (char*)NULL have different representations in any way). Technically it could also matter on systems where void* and char* are passed differently, but I don't suppose any of those exist, or will.

I do not think it should matter, unless there is a compiler bug, because 0 is a valid null pointer constant, so the compiler should be expected to account for this.