This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Scott, >Date: Tue, 03 May 2005 15:56:26 -0800 >From: "Scott Swank" <address@hidden> >Organization: NOAA/NWS >To: Steve Emmerson <address@hidden> >Subject: Re: 20050429: LDM - Binaries available? >Keywords: 200504291922.j3TJMbKx001883 The above message contained the following: > EXEC calls runDecoder.sh which in turn decides which script to call to > process the data in the queue. In this case, the script ldm_metar.ksh > is called to process and when it is called, it logs this to its own log. Ah. [snip] > > Does this happen if you replace > > > > EXP ^(METAR) > > EXEC -wait /apps/datatools/runDecoder.ksh > > > > with, for example, > > > > EXP ^(METAR.*) > > PIPE -close /apps/datatools/metarDecoder.ksh \1 I'm sorry, the above should have had a space between the ".ksh" and the "\1" instead of a tab, i.e., EXP ^(METAR.*) PIPE -close /apps/datatools/metarDecoder.ksh \1 > Did this, and now I'm back to overwriting/multiple calls of the same > file. Ie: I get 3 files inserted into the queue at roughly the same > time, the last one gets PIPE'd 3 times and my metarDecoder script gets > called 3 times on the 3rd product. Was it invoked with three different arguments? It should have been. > > The above is more efficient than using an EXEC entry in the pqact(1) > > configuration-file coupled with a script that uses pqcat(1) to obtain > > the desired data-product. It would require, however, that the script be > > rewritten to read the data-product from standard input rather than use > > pqact(1). > Easily done and tested, but didn't work out. Is there a way to force > PIPE to perform the -wait like on an EXEC? The "-close" option will cause the data-product to be completely written to the pipe before another decoder is executed. It will also cause the pipe to be closed after the data-product is written. I suggest replacing the decoding script with one that merely logs the argument (e.g., "METAR_vrh_SAUS20KNKA.86263.123215455") to verify that the decoder is being invoked with a different argument each time. > Thanks, > Scott Regards, Steve Emmerson