Re: why is this not a bug? (popen, pclose)

(see below) > On 7/13/00 at 2:04 PM, bill@numerical.com (Bill Rausch) expostulated: > > > > > > >Actually, popen is returning non-zero regardless of > > >the success of the launch of your program. It's > > >merely returning a valid file pointer if it was able > > >to fork and open a pipe. Apparently fork is telling > > >popen that it was successful regardless of the outcome > > >of the attempt to actually run your program. > > > > > > Well I'll be. I just ran a simple experiment to verify what you said by > > trying to launch a non-existent executable. I did redirect (2>&1) the > > output so that I could read it in the program and got: > > sh: /xbin/ls: not found. > > When I do pclose I then get a status of 32512 which when masked and shifted > > becomes 127. According to the (HP-UX) man page, 127 is what pclose will > > return when the popen failed to launch the shell command properly. Hmm... I was just reading the pclose man page again and in the BUGS section it says: Failure to execute the shell is indistinguishable from the shell's fail-ure to execute command, or an immediate exit of the command. The only hint is an exit status of 127. So, perhaps the PHP source should change to include testing the return value of php for a value of 127 (or 32512) and if so, return 0 in that case as well? I don't know who exactly to notify of this, but I'm assuming someone can forward this on to the right people to look into? > > When I tried running a command that works ok I get pclose to return zero > > like it should have. My conclusion is that you can use the popen, do > > whatever processing there is to do, and then do the pclose being sure to > > check the exit code. Until that point though, there is no way to tell if > > the popen actually worked or not. Again, my man page says: The popen() function returns NULL if the fork(2) or pipe(2) calls fail, or if it cannot allocate memory. But I suspect fork/pipe are still succeeding regardless of an invalid command since the execution of the command would happen after fork (right?) > > It seems that this should be a bug but I'm not sure how PHP can be made to > > detect it. A simple C program I wrote to test popen/pclose works very > > similarly to what the PHP does. Everything seems fine but in fact it > > isn't. You don't know it until the pclose is called though. The only work > > around I can think of is to have PHP rewritten to implement its own popen > > instead of using the C stdlib one. > > > > The PHP documentation should probably be rewritten to reflect what is > > currently happening also. > > > > Well, I'm not sure if this means it is or isn't a bug, but it does seem like > peculiar behaviour. I understand more now about Unix and the internal workings > of applications running in it (a bit), and while I can see how a non-zero return > can be more informative, a problem still remains, which is this: > > Having started out trying to get mail() to work, I still am not clear why it > would not. So since I notice that a couple of you (Bill, Philip) are experienced > with BSD and might be familiar with OSX, let me ask you if you can give me some > idea why mail would fail on my machine, and perhaps some details about your own > configurations on similar machines to mine. > > To summarize (this is in a previous post about 2 million messages ago) - > > php.ini correctly tells php the location of sendmail. Sendmail can send a > message fine from another application (mailviewer). mail() returns 1 ( no matter > where php thinks sendmail is - and mail is never sent. > > Should I interpret the 1 returned as a failure (doesn't seem right)? Or success > with the problem lying somewhere else? And what can I do to get it to work? I > hate to plead, but the fact is that while I'm a pretty good programmer in > scripting languages, I'm a little out of my depth when we start talking Unix > nitty gritty... You can always bypass mail() completely and do something like this instead: <?php $fd = popen("/path/to/sendmail -oi -t -oeq", "w"); fwrite($fd, "From: Joe <joe@joe.com>\n"); fwrite($fd, "To: Bob <bob@bob.com>\n"); fwrite($fd, "Subject: blah blah\n"); fwrite($fd, "\n"); fwrite($fd, "my message, etc...\n"); pclose($fd); ?> If *that* doesn't work (minus any syntax errors of course :) there is something really wrong with your system... you could easily put that in a function that mimiced mail()'s arguments and be on your way... -philip