RE: [Refdb-users] refdbc and php4

[Markus H. <mar...@mh...>]

Hi there,

Alan Anderson writes:
 > There are two difficulties with trying to run refdbc from within a CGI application (this includes
 > PHP).  First, refdbc is compiled with CGI support builtin, and it tests the environment to determine
 > whether it is running as a CGI application or a standalone application.  This test is simply the
 > existence of the REQUEST_METHOD environment variable.  Since we are running refdbc from within
 > another CGI application this variable exists, so refdbc assumes it is running in CGI mode.  This
 > test seems to override the -C commandline option (didn't really take the time to find out if this is
 > exactly true).  My solution was to #undef REFDB_CGI at the top of refdbc.c and recompile refdbc to

This analysis is pretty much correct. I've applied the suggested fix,
i.e. checking for -C at the very beginning.

 > The second problem is that refdbc attempts to call fgets in several places regardless of whether it
 > is run in "batch" mode.  Attached is a diff file which should show you where fixes are needed, but
 > you'll have to fight through some garbage changes that I made for debugging.  In two or three places
 > there is a test like
 > 
 > 	if (n_read_file || n_read_stdin) {
 > 
 > If this test succeeds, then fgets is called (not directly, but eventually in each case--I'm not
 > exactly sure what difficulty this causes, but I'm guessing the web server hasn't provided STDOUT or
 > something--in any case, the fgets fails).  If the test fails, then the string sent to the refdbd
 > server is not completed and you get the "unknown command" error in the log.  I changed these lines
 > to also test for batch mode:
 > 
 > 	if ((n_read_file || n_read_stdin) && !n_batchmode) {
 > 
 > In this case, it does not call fgets AND the command string is correctly created and sent to refdbd.
 > 

I'm not sure whether this is the correct fix. Both the com_pickref()
and the com_deleteref() functions accept a list of ID values
(e.g. from a previous getref -s ID call) on either stdin (in batch
mode) or with the -f command line option (interactive mode). Your
suggested fix would preclude the former use. I think we run into
trouble right here:

  if (!isatty(fileno(stdin))) { /* if we receive data on stdin via a redirection or a pipe */
    n_read_stdin = 1;
  }

If a CGI app runs refdbc, stdin won't be a tty, and refdbc incorrectly
assumes that data are waiting at stdin. I'm afraid I'll need another
command line switch to keep refdbc from reading stdin when it's not
supposed to.

 > I hope this makes sense, and I hope Markus doesn't take offense to the "logic" comment above.  I

Don't worry. A flaw is a flaw, and it needs to be fixed. On the
contrary, I appreciate that you've done most of the debugging.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de