Loading ...
Sorry, an error occurred while loading the content.

varAdjust.tcl: Fine reading fid file, not working on stdin from gzcat

Expand Messages
  • nmrkev
    Hi all: I ve got a quick and trivial question to run by Frank and any other varAdjust.tcl users: This is working great when reading a file as input, and
    Message 1 of 2 , Jan 5, 2008
    • 0 Attachment
      Hi all:
      I've got a quick and trivial question to run by Frank and any
      other varAdjust.tcl users: This is working great when reading a file
      as input, and writing out to either a file or to stdout. However, I'm
      running into issues whenever I try to have it read from a pipe that's
      coming out of gzcat, e.g.:

      gzcat fid.gz | varAdjust.tcl -expand -order...

      gives:

      chandra(66)% test.com
      Fid Count: 2816 Exp Count: 1 FidSize: 1534 Word Size: 4

      DATAIO File Read Error 0.
      Request: 6136 Actual: 3836.
      DATAIO File Read Error 0.
      Request: 6136 Actual: 1920.
      DATAIO File Read Error 0.of 2816
      Request: 6136 Actual: 5816.
      DATAIO File Read Error 0.
      Request: 6136 Actual: 1920.
      DATAIO File Read Error 0.of 2816
      Request: 6136 Actual: 5816.
      DATAIO File Read Error 0.
      Request: 6136 Actual: 1920.
      DATAIO File Read Error 0.of 2816
      Request: 6136 Actual: 5816.
      ....

      and so on, where the exact same parameters work if I include a "-in
      fid" flag to have it read from a file. The differing sizes of
      "Actual" from DATAIO make me think it's somehow or another fallen out
      of sync with the data coming out of gzcat.

      Yes, the workaround is obvious.

      And yes, I'm still curious to know if there's any better solution.

      Cheers,
      Kevin
    • delaglio@nmrscience.com
      Oh my! My mistake, friends. Scripts like varAdjust.tcl need to be patient when reading from a pipeline. So, the occurences of sysRead in this script
      Message 2 of 2 , Jan 7, 2008
      • 0 Attachment
        Oh my!

        My mistake, friends. Scripts like "varAdjust.tcl" need to be patient
        when reading from a pipeline. So, the occurences of "sysRead" in
        this script should be replaced with the blocking-read version "sysReadB"
        (i.e. a version that waits till data is available to be read).

        So, you can edit "com/varAdjust.tcl" and replace the three uses of
        "sysRead" with "sysReadB" ... that should fix the problem.

        Quoting nmrkev <Kevin.Gardner@...>:

        > Hi all:
        > I've got a quick and trivial question to run by Frank and any
        > other varAdjust.tcl users: This is working great when reading a file
        > as input, and writing out to either a file or to stdout. However, I'm
        > running into issues whenever I try to have it read from a pipe that's
        > coming out of gzcat, e.g.:
        >
        > gzcat fid.gz | varAdjust.tcl -expand -order...
        >
        > gives:
        >
        > chandra(66)% test.com
        > Fid Count: 2816 Exp Count: 1 FidSize: 1534 Word Size: 4
        >
        > DATAIO File Read Error 0.
        > Request: 6136 Actual: 3836.
        > DATAIO File Read Error 0.
        > Request: 6136 Actual: 1920.
        > DATAIO File Read Error 0.of 2816
        > Request: 6136 Actual: 5816.
        > DATAIO File Read Error 0.
        > Request: 6136 Actual: 1920.
        > DATAIO File Read Error 0.of 2816
        > Request: 6136 Actual: 5816.
        > DATAIO File Read Error 0.
        > Request: 6136 Actual: 1920.
        > DATAIO File Read Error 0.of 2816
        > Request: 6136 Actual: 5816.
        > ....
        >
        > and so on, where the exact same parameters work if I include a "-in
        > fid" flag to have it read from a file. The differing sizes of
        > "Actual" from DATAIO make me think it's somehow or another fallen out
        > of sync with the data coming out of gzcat.
        >
        > Yes, the workaround is obvious.
        >
        > And yes, I'm still curious to know if there's any better solution.
        >
        > Cheers,
        > Kevin
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.