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

At 1:16 PM -0700 7/13/00, Michael Teter wrote: >--- Bill Rausch <bill@numerical.com> wrote: >...snip... >> Yes, popen returns a valid file pointer (like fopen >> does) if it was able to >> launch the program you requested. This file pointer >> is how you send input >> to the other program (if you used a "w") or how you >> read its output (if you >> used an "r"). If popen was unable to execute your >> command, it returns a >> NULL just like fopen does when it fails. > >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. Bill --- Bill Rausch, Software Development, Unix, Mac, Windows Numerical Applications, Inc. 509-943-0861 bill@numerical.com