RE: [Refdb-users] refdbc and php4

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

Hi Alan & Howard,

I've been revisiting the problem of running refdbc from Perl or PHP
today and ran into a small calamity: I can't reproduce the second
problem Alan was mentioning, namely the fact that refdbc calls fgets
and fails. What I did so far is to apply the first fix Alan
suggested. refdbc now will not go into CGI mode if the -C command line
option is present. I did not add the other suggested fixes (i.e. the
tests for n_batchmode) as they would break some refdbc functionality.

If I then run the following Perl script:

---8<---
#!/usr/bin/perl -w

system "/home/markus/prog/refdb/src/refdbc -d pseudotest -C getref :ID:=1 -c stdout";
---8<---

it works just fine, whereas it should fail with dubious error messages
according to your posts. Could you please provide an example of a call
that fails, or maybe an example Perl script that reproduces the problem?

BTW I've used a small test program to verify my hypothesis that the
following check:

if (!isatty(fileno(stdin))) {
   /* read from stdin */
...
}

is responsible for the problem you reported. Turns out that this call
still reports that stdin is connected to a tty even if the program is
called from a Perl script, so my assumption was wrong. Now I'm stymied
as to why fgets would ever be called when refdbc is run from a script.

regards,
Markus

Markus Hoenicka writes:
 >  > 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.
 > 

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