Thread: [Refdb-users] Curious refdbc -C "getref ..." behaviour
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-users
|
From: David N. <dav...@bi...> - 2004-03-28 10:37:22
|
I have observed some curious behaviour regarding getref when used with refdbc's batch mode. In summary: - Using getref to output to file in refdbc interactive mode: works for all tried formats (scrn, ris, risx, html, xhtml). - Using getref to output to file in refdbc batch mode: works only for ris format, fails with scrn, risx, html, xhtml. --------------------------------------------------------------------------------------------- Demonstrating the problem: Let's output a reference to screen: These all work: refdbc -C "getref -t scrn :ID:=7" refdbc -C "getref -t risx :ID:=7" refdbc -C "getref -t ris :ID:=7" refdbc -C "getref -t html :ID:=7" refdbc -C "getref -t xhtml :ID:=7" Now, let's output to file: This works: refdbc -C "getref -o foo.ris -t ris :ID:=7" These do not work: refdbc -C "getref -o foo.txt -t scrn :ID:=7" refdbc -C "getref -o foo.xml -t risx :ID:=7" refdbc -C "getref -o foo.html -t html :ID:=7" refdbc -C "getref -o foo.xhtml -t xhtml :ID:=7" What is written to the file in each failed case is the following text: ........................ select failed ........................ Let's use refdbc's interactive mode to make sure it's a problem with the batch mode: These all work: refdbc: getref -o foo.txt -t scrn ":ID:=7" refdbc: getref -o foo.xml -t risx ":ID:=7" refdbc: getref -o foo.ris -t ris ":ID:=7" refdbc: getref -o foo.html -t html ":ID:=7" refdbc: getref -o foo.xhtml -t xhtml ":ID:=7" --------------------------------------------------------------------------------------------- Workaround: The workaround is obvious: use ris format when scripting, work in interactive mode if using other formats. This, however, limits the use of refdbc in scripting -- one of the stated design goals of refdb. |
|
From: Markus H. <mar...@mh...> - 2004-03-29 21:56:57
|
Hi David, David Nebauer writes: > This works: > > refdbc -C "getref -o foo.ris -t ris :ID:=7" > > These do not work: > > refdbc -C "getref -o foo.txt -t scrn :ID:=7" > refdbc -C "getref -o foo.xml -t risx :ID:=7" > refdbc -C "getref -o foo.html -t html :ID:=7" > refdbc -C "getref -o foo.xhtml -t xhtml :ID:=7" > But these are supposed to work: refdbc -o foo.xhtml -t xhtml -C getref :ID:=7 refdbc -o foo.xhtml -t xhtml -C getref :KW:="titanium oxide" refdbc in batch mode accepts all options to the specified command on the command line. There is no need to enclose the whole getref command in quotes. The obvious advantage is that you get rid of one level of quoting. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: David N. <dav...@bi...> - 2004-03-30 09:03:37
|
Markus Hoenicka wrote: >refdbc in batch mode accepts all options to the specified command on >the command line. There is no need to enclose the whole getref command >in quotes. The obvious advantage is that you get rid of one level of >quoting. > > Hmm. Quite right. The reason I began quoting refdb batch commands was that the first command I ever tried executing in batch mode was "getref -h". When I tried it without quotes << refdbc -C getref -h >>, it gave the generic refdbc help. When I tried it with quotes << refdbc -C "getref -h" >>, it worked. My conclusion was that batch commands needed to wrapped in quotes and I have done so ever since. In retrospect it is easy to see that, without quotes, refdbc interpreted the "-h" as an option to refdbc and ignored the "-C getref", effectively executing << refdbc -h >>. This is probably the only case where quotes are necessary, and probably doesn't even classify as a bug. One way to fix this behaviour might be to change the refdbc help option to "--help". An easy workaround might be to simply document this behaviour in the manual. Regards, David. |
|
From: Marc H. <mar...@fr...> - 2004-03-30 12:52:39
Attachments:
refdbc.c_checkcmdline.patch
|
On Tue, 30 Mar 2004, David Nebauer wrote: > Markus Hoenicka wrote: > > >refdbc in batch mode accepts all options to the specified command on > >the command line. There is no need to enclose the whole getref command > >in quotes. The obvious advantage is that you get rid of one level of > >quoting. > Hmm. Quite right. > > The reason I began quoting refdb batch commands was that the first > command I ever tried executing in batch mode was "getref -h". The other reason why you quoted the -C argument, is probably some familiarity with other unix command line tools, most of them asking for quoting of nested commands for a number of reasons. The first reason that comes to mind is that it easily prevents ambiguities, as you noticed. > In retrospect it is easy to see that, without quotes, refdbc interprete= d > the "-h" as an option to refdbc and ignored the "-C getref", effectivel= y > executing << refdbc -h >>. Mmmm... I don't think user input should ever be "ignored", but rather trigger an error message, but this is another story. > This is probably the only case where quotes are necessary, and probably > doesn't even classify as a bug. One way to fix this behaviour might be > to change the refdbc help option to "--help". An easy workaround might > be to simply document this behaviour in the manual. I stumbled on this issue one year and a few days ago. Actually, the issue is a bit more complex that "quotes or not quotes", because quoting the -C argument still more or less works: the -C argument is parsed again later when it dodges the first parsing thanks to quotes. Why only "more or less" works ? Because the -C argument has a finite length, and is silently truncated. For instance, if you call: refdbc -C 'getref :ID:>0 -t html -s N1N2ADURAVU1U2U4U5' you get the same result as: refdbc -C getref :ID:>0 -t html -S=A0N1N2AD I sent one year ago to Markus the attached patch, which checks if the (truncated) -C argument is a valid command before the second parsing and tells the user if not, effectively preventing silent commmand line truncation or other silent weird errors in case the user does not the read the docs and quotes the -C argument. This patch definitively makes the "no quotes" choice. I personnally favor quoting and think this is the wrong choice, but at least this patch reduce confusion by making a choice, and is only 3 lines long. Cheers, Marc. |
|
From: Markus H. <mar...@mh...> - 2004-03-31 00:07:31
|
Marc Herbert writes:
> > In retrospect it is easy to see that, without quotes, refdbc interpreted
> > the "-h" as an option to refdbc and ignored the "-C getref", effectively
> > executing << refdbc -h >>.
>
> Mmmm... I don't think user input should ever be "ignored", but rather
> trigger an error message, but this is another story.
>
The manual says:
-h
Displays help and usage screen, then exits.
This behaviour is documented. Asking for help should never do anything
but display the help, otherwise users might be reluctant to run it at
all.
> --- refdbc.c 2003/03/11 18:50:42 1.1
> +++ refdbc.c 2003/03/11 21:07:58
> @@ -338,6 +338,11 @@
> the_pager[PREFS_BUF_LEN-1] = '\0';
> break;
> case 'C':
> + if (!find_command(optarg, commands))
> + {
> + fprintf (stderr, "%s: No such command for refdb.\n", optarg);
> + return (-1);
> + }
> strncpy(the_cmd, optarg, 31);
> the_cmd[31] = '\0';
> n_batchmode = 1;
This unfortunately breaks the refdbc -C "getref -h" workaround. I'll
have to figure out a way to have both, not one or the other.
regards,
Markus
--
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
|
|
From: Markus H. <mar...@mh...> - 2004-03-31 17:26:46
|
Markus Hoenicka writes: > This unfortunately breaks the refdbc -C "getref -h" workaround. I'll > have to figure out a way to have both, not one or the other. > I've figured out something that (hopefully) satisfies all your needs. The current CVS version of refdbc.c does the following: 1) refdbc -h runs the refdbc help, then exits 2) refdbc -C getref -h runs the getref help, then exits 3) refdbc -C yaddayadda complains about unknown command, then exits The latter is done along the lines of Marc's suggested patch. Let me know if this behaviour still causes problems. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: David N. <dav...@bi...> - 2004-04-01 11:56:36
|
Markus Hoenicka wrote: >I've figured out something that (hopefully) satisfies all your >needs. The current CVS version of refdbc.c does the following: > > Thanks, Markus. That solves my problem. Regards, David. |
|
From: Markus H. <mar...@mh...> - 2004-03-31 00:07:27
|
Hi David, David Nebauer writes: > The reason I began quoting refdb batch commands was that the first > command I ever tried executing in batch mode was "getref -h". > > When I tried it without quotes << refdbc -C getref -h >>, it gave the > generic refdbc help. > > When I tried it with quotes << refdbc -C "getref -h" >>, it worked. > > My conclusion was that batch commands needed to wrapped in quotes and I > have done so ever since. > > In retrospect it is easy to see that, without quotes, refdbc interpreted > the "-h" as an option to refdbc and ignored the "-C getref", effectively > executing << refdbc -h >>. > I've never bothered about this ambiguity as I assumed a script would never ask for help. However, if you run refdbc in batch mode manually, you might indeed want to see a command help instead of the generic help. > This is probably the only case where quotes are necessary, and probably > doesn't even classify as a bug. One way to fix this behaviour might be > to change the refdbc help option to "--help". An easy workaround might > be to simply document this behaviour in the manual. > The manual contains a few lines about the quoting issue. I'll add a line that explains how to display the command help by quoting the command. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: David N. <dav...@bi...> - 2004-03-30 13:41:43
|
Marc Herbert wrote: >Why only "more or less" works ? Because the -C argument has a finite >length, and is silently truncated. For instance, if you call: > > I discovered the -C truncation myself a little while back. I wrote a small script which copied a risx template to a temporary file. I edited the temporary file to add a reference and then used the << refdbc -C addref filename >> command. The temporary file name was generated using the 'date' command. I can't remember which options I used but it resulted in a _long_ filename. This approach initially would not work. It took a very long time to figure out that the problem had to do with -C truncation. I simply worked around the issue by using a shorter filename. I didn't report it as a bug as I figured few people would ever do what I was doing (and I didn't have time to investigate the extent of the issue). Always good to know I'm not alone... Any idea why the truncation occurs? Regards, David. |
|
From: Marc H. <mar...@fr...> - 2004-03-30 18:03:57
|
On Tue, 30 Mar 2004, David Nebauer wrote: > I discovered the -C truncation myself a little while back. I wrote a > Any idea why the truncation occurs? It's easy to find out if you know a bit of C and have a look at the code near my patch: only the first 31 characters of the -C argument are considered, which is more than enough to hold every potential -C command (see the array "commands" at the beginning of the same refdbc.c file). All this is consistent indeed. But when some users "intuitively" do something bad (a quoted thus long -C argument), and when the program does not report any error for that, things can go very wrong. |
|
From: Markus H. <mar...@mh...> - 2004-03-31 16:41:21
|
Marc Herbert writes: > But this does not break: > > refdbc -C getref -h > > which is the documented syntax, right ? > > I'm confused. > Unless I'm entirely confused, we're looking at the following: 1) refdbc -C getref -h refdbc displays the generic help and exits. This is documented and will not break by applying the patch 2) refdbc -C 'getref -h' refdbc displays the getref command help and exits. This is not documented, works nonetheless, but will break by applying the patch. "getref -h" is no known command, whereas "getref" is. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Marc H. <mar...@fr...> - 2004-03-31 08:12:57
|
On Wed, 31 Mar 2004, Markus Hoenicka wrote:
> > --- refdbc.c 2003/03/11 18:50:42 1.1
> > +++ refdbc.c 2003/03/11 21:07:58
> > @@ -338,6 +338,11 @@
> > the_pager[PREFS_BUF_LEN-1] = '\0';
> > break;
> > case 'C':
> > + if (!find_command(optarg, commands))
> > + {
> > + fprintf (stderr, "%s: No such command for refdb.\n", optarg);
> > + return (-1);
> > + }
> > strncpy(the_cmd, optarg, 31);
> > the_cmd[31] = '\0';
> > n_batchmode = 1;
>
> This unfortunately breaks the refdbc -C "getref -h" workaround. I'll
> have to figure out a way to have both, not one or the other.
But this does not break:
refdbc -C getref -h
which is the documented syntax, right ?
I'm confused.
|
|
From: Marc H. <mar...@fr...> - 2004-03-31 17:23:03
|
On Wed, 31 Mar 2004, Markus Hoenicka wrote: > Unless I'm entirely confused, we're looking at the following: > > 1) refdbc -C getref -h > > refdbc displays the generic help and exits. This is documented and > will not break by applying the patch Ah OK. I naively thought that all arguments after the "-C command" were ignored by refdbc and passed to the "command". Just like I naively thought that: refdbc whatever -h whatever would syntax error. Of course, a syntax error could also...=A0display a short help, as most tools do :-) > 2) refdbc -C 'getref -h' > > refdbc displays the getref command help and exits. This is not > documented, works nonetheless, but will break by applying the > patch. "getref -h" is no known command, whereas "getref" is. Thanks for the clarification. |
|
From: Markus H. <mar...@mh...> - 2004-03-31 17:54:57
|
Marc Herbert writes: > Ah OK. I naively thought that all arguments after the "-C command" > were ignored by refdbc and passed to the "command". > refdbc uses GNU getopt to read the command line (which is also mentioned in the manual). This version of getopt is insensitive to the option/argument order, except when you use '--'. That is, these two are absolutely equivalent: refdbc -h -C getref refdbc -C getref -h > Just like I naively thought that: > > refdbc whatever -h whatever > > would syntax error. Of course, a syntax error could also...=A0display a > short help, as most tools do :-) > With GNU getopt, this is no syntax error, hence no error message. The first "whatever" is the first non-option argument to refdbc. Unless you call a command that utilizes an argument, it will be ignored. Try the following: refdbc mydata.ris -C addref regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X