system calls
in [Unix Programming]
|
From: Phred Phungus on 8 Mar 2010 01:45 Seebs wrote: > On 2010-03-08, Phred Phungus <Phred(a)example.invalid> wrote: >> I tried exec on the terminal, and it disappeared. My experiments with >> other ways to invoke a shell aren't looking so good. In particular, I >> see no output for one of the printf's and can't see for the life of me >> why it is ls'ing twice: > > You know, I've been watching you ignore any suggestion that maybe reading > documentation might help for a few months now. > > Has it ever occurred to you that when you want to know what something does, > a good starting point might be to READ THE DOCUMENTATION? > >> ID = fork(); >> printf ("ID is %d", ID); > > Problem number one: You aren't printing a newline. In general, you should > make sure that any message you want to see ends with a newline. > > But here we are. You've called fork(), so you now have two programs running. > In one, ID is non-zero. In the other it's zero. > > But, since you don't DO anything with that ID (say, make following behavior > conditional on it), BOTH OF THEM RUN ALL THE SAME CODE. > > This is really, really, basic. You called fork(). You have two processes. > They are doing the same thing. The only difference between them is the > value stored in "ID", and you haven't tested it. > >> ret = execl ("/bin/ls", "ls", "-1", (char *)0); > > So now each of them executes ls. There is no reason for either of them not > to, so they both do. > > If you can't see this, and you can't be bothered to read the documentation, > and you can't somehow be convinced not to randomly change things from the > examples you're working from and then complain that it doesn't make sense... > > Why are you posting? You're taking every step possible to prevent yourself > from learning anything. > >> printf ("ret is %d", ret); > > Unless execl() fails, this is never reached. > > Seriously, you need to start reading the man pages. Nothing here is not > CLEARLY explained in the documentation. If you would read the documentation > before asking questions, and ask questions that show that you've made some > kind of real effort to figure out what's going on, you'd get more helpful > responses. > > -s I don't post to be told that I'm putting forth no effort. Why don't you tell me what I didn't read today, peter, because I did a fuckload of it, including man pages, which are some of the least useful reference materials I've ever seen. -- fred
From: Ian Collins on 8 Mar 2010 02:32 Phred Phungus wrote: > > I don't post to be told that I'm putting forth no effort. Why don't you > tell me what I didn't read today, One of W. Richard Stevens Unix programming books? They will give you the background to make better sense of man pages and other documentation. -- Ian Collins
From: Seebs on 8 Mar 2010 03:50 On 2010-03-08, Phred Phungus <Phred(a)example.invalid> wrote: > I don't post to be told that I'm putting forth no effort. You aren't *showing* effort. > Why don't you > tell me what I didn't read today, peter, because I did a fuckload of it, > including man pages, which are some of the least useful reference > materials I've ever seen. The fork() manpage: fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points: Why should it surprise you that, having created a DUPLICATE of a process which is about to call ls, you see ls called twice? I have a program which is about to print "hello". I first make a DUPLICATE of that program. What do I have now? Two programs which are about to print "hello". How about the execl() manpage: RETURN VALUE If any of the exec() functions returns, an error will have occurred. The return value is -1, and the global variable errno will be set to indicate the error. So, why don't you see anything from the second printf? Because, since ls was successfully called (which you knew), no error occurred, therefore exec*() WILL NOT RETURN. And if it doesn't return, why should anything after it be executed? I guess I should clarify the comment about effort. I do grant that you certainly seem to be plugging away at this stuff. However, you seem to be doing it in a way which is pretty much incapable of yielding good results. You spend a lot of time experimenting, but you don't seem to spend any time trying to develop a usable abstract model of how things work. You end up spending a lot of time asking about extremely arcane details of how compiled code actually runs on a processor, but never seem to form the abstractions you'd need to make sense of it. I am pretty sure you need to develop a higher-level view of what you're studying -- and as long as you're flooding yourself with details which are irrelevant, you're not going to be able to get that big picture. Here's what you are apparently missing: fork() duplicates a process, with the significant exception being the return code of fork(). exec() replaces a process with another process. If you wish to call an external program, the usual idiom is this: int pid; if ((pid = fork()) != 0) { if (pid == -1) { fprintf(stderr, "error: fork failed: %s\n", strerror(errno)); } else { int status; wait(&status); } } else { execl("/bin/ls", "ls", "-1", (char *)0); fprintf(stderr, "error: execl failed: %s\n", strerror(errno)); exit(EXIT_FAILURE); } If fork fails, we end up with pid == -1, so we announce the failure. Otherwise, there are now two processes; in one, pid was zero (the child process), and in the other, pid was non-zero (the parent process, where "pid" is the pid of the child). In the parent, we wait for the child process to complete. In the child, we call execl() to replace the duplicate of the original program with a call to ls. If execution of this process continues, that means execl() failed, so we print an error message and exit. There are THOUSANDS of web pages which show this code, or code much like it. It really shouldn't require this much effort -- if it does, you're doing something wrong. If what you're doing isn't working, don't just do the same thing harder. Figure out why it isn't working. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Ivan Shmakov on 8 Mar 2010 06:30 >>>>> "PP" == Phred Phungus <Phred(a)example.invalid> writes: [...] PP> I don't post to be told that I'm putting forth no effort. Why PP> don't you tell me what I didn't read today, peter, because I did a PP> fuckload of it, including man pages, which are some of the least PP> useful reference materials I've ever seen. I wonder, may Info suit you better? Say: http://www.gnu.org/software/libc/manual/html_node/Processes.html http://www.gnu.org/software/libc/manual/html_node/Process-Creation-Concepts.html PS. However, as a side note: when faced something which doesn't immediately fit his or her mind, the wise may ask him- or herself, “am I dumb?” The dumb may ask, “are you dumb?”, too. -- FSF associate member #7257
From: Dominic Fandrey on 8 Mar 2010 07:11
On 08/03/2010 07:45, Phred Phungus wrote: > ... > including man pages, which are some of the least useful reference > materials I've ever seen. Ouch! Some of us actually write these things. I even write man pages for /shell-scripts/. And to me they are often the most useful form of documentation. They tend to be quite extensive and full of useful examples. They even work under the most dire circumstances, e.g. on a rescue shell over a serial line. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |