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

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. > > 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. > > 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... Does php need to compiled in a way that tells it to use sendmail? (I'm assuming not since the php.ini file tells it where it is). Are there simple instructions to help me write a c program and compile and run it to test what's going on? are the values for sendmail_from or smtp in the php.ini file relevant here? I have a mean boss.... dan Dan Donaldson omnivore@sympatico.ca