RE: [Refdb-users] refdbc and php4

[<al...@ru...>]

The example you show is pretty much as I remember my initial attempts.  I've
attached a file (refdbc-test.pl) which is one of the initial files I used. 
You'll notice that I use "refdbc-nocgi," so you'll need to change that line.

I've also attached two other files (refdbcgi.pl and RefDB_CGI.pm) which make up
the application I started.  Much of the functionality is presented, but not
functional.  You can add references using the forms, and you should be able to
submit a query and get results, but you cannot modify records and the query
results are probably not that pretty--I got distracted with "real" work this
week and last.  To run this application you'll need a few Perl Modules,
specifically CGI::Application, HTML::Templates, and (indirectly) CGI.  Beyond
that you should only need to modify the one line which specifies the refdb
executable and place the two files in a directory with executable permissions
within your webserver's file space.

Can you attach a patch for the changes which keep refdbc out of CGI mode with
the  -C option?  If I get the time, I'll look at how it works on my system.

Hope this helps,

Al


Quoting Markus Hoenicka <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
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Refdb-users mailing list
> Ref...@li...
> https://lists.sourceforge.net/lists/listinfo/refdb-users
> 
> 




-------------------------------------------------
This mail sent by http://webmail.rushmore.com