20040616: Question about pqact.conf

>From: "John R. Jackson" <address@hidden>
>Organization: Purdue
>Keywords: 200406162357.i5GNv6tK002466 LDM pqact.conf

JJ,

>I had my first experience setting up a pqact.conf entry and it took quite
>a bit of debugging print statements to figure out how I messed it up :-).
>
>All I wanted to do was grab all the CRAFT data products and drop them
>in a scratch disk.  Looking at the example pqact.conf file that got
>installed I came up with this:
>
>  CRAFT                "(.*)"
>       FILE    data/CRAFT/\1
>
>The first (very minor) problem was when I did a copy/paste of the command
>to check the syntax:
>
>  # su ldm -c 'ldmadmim pqactcheck'
>  ksh: ldmadmim:  not found
>
>Well, yeah, that's true :-).  It's a typo in the command name in the
>sample pqact.conf file comments (ldmadmim instead of ldmadmin).

OK, thanks for reporting this typo.  We will fix it in the next
LDM release.

>Anyway, to make a long story short, the examples in the file all use
>double quotes around the pattern, but I don't see anything in the code
>that removes them.  So they go into the regex and, of course, cause all
>the matches to fail so I was getting absolutely nothing.
>
>Is that a goof in the examples, or am I missing something?

It _is_ a goof in the examples, sorry.

>The example
>data products don't really have double quotes in their names, do they?

No.

>In any case, removing the double quotes from the above (and the parens
>which were not really needed) got everything working.  I also added
>"-close" to deal with the number of file descriptor issue.

Good move.  The '-close' option is important on many FILE actions.

>Just for curiosity, are there any likely patterns that would include
>whitespace, and how would you enter them if you cannot use quotes?

There are no patterns that use non-space white space in IDD product
headers.  This is the reason that the whitespace between the
feed name and the header matching regular expression must be a 
tab:

CRAFT   .*      FILE    data/CRAFT/\1

is actually:

CRAFT<tab>.*<tab>FILE<tab>data/craft/\1

which is equivalent to:

CRAFT<tab>.*
<tab>FILE<tab>data/craft/\1

which is equivalent to:

CRAFT<tab>.*
<tab>FILE
<tab>data/craft/\1

>It looks like spaces might be OK because the parser wants a tab between
>fields, so is the theory that we'll never see a data product with a
>tab in the name?

Yes, you will absolutely never see a tab in a product header.

>One would hope not :-), but it's just an end case I wondered about.

You have scoped things out exacly correctly.  Tabs are used for white
space everywhere except in regular expressions matching product headers.

Cheers,

Tom
--
**************************************************************************** <
Unidata User Support                                    UCAR Unidata Program <
(303)497-8643                                                  P.O. Box 3000 <
address@hidden                                   Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
---------------------------------------------------------------------------- <
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.