SourceForge has been redesigned. Learn more.

This looks like a bug?

  • William

    William - 2008-05-07

    Shouldn't the parse on line 8 remove the blanks between the fields?

    [root@laptop USGS]$ sort_usgs
    +++ "LINUX COMMAND /src/USGS/sort_usgs"
    6 - Do while queued() > 0
    >F> QUEUED => "957"
    >L> "0"
    >O> ">" => "1"
    >>> "1"
    +++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. +++

     7 *-*   Parse Pull  Record
       >>>     "aberdeen-e.gz            45.0   98.0     "
     8 *-*   Parse value Record with Name Lat'.0' Lon'.0' .
       >V>     RECORD => "aberdeen-e.gz            45.0   98.0     "
       >>>     "aberdeen-e.gz            45.0   98.0     "
       >L>     ".0"
       >>>     ".0"
       >>>     "aberdeen-e.gz"
       >>>     "           45"
       >L>     ".0"
       >>>     ".0"
       >>>     "   98"
       >.>     "     "
     9 *-*   Call lineout(Output), left(Lat,6) left(Lon,6) Name;
       >V>     OUTPUT => "usgs_sorted"
       >A>     "usgs_sorted"
       >V>     LAT => "           45"
       >A>     "           45"
       >L>     "6"
       >A>     "6"
       >F>     LEFT => "      "
       >V>     LON => "   98"
       >A>     "   98"
       >L>     "6"
       >A>     "6"
       >F>     LEFT => "   98 "
       >O>     " " => "          98 "
       >V>     NAME => "aberdeen-e.gz"
       >O>     " " => "          98  aberdeen-e.gz"
       >A>     "          98  aberdeen-e.gz"
       >>>     "0"
    • Nobody/Anonymous

      Rick, even tho your solution works the one from mrmunhun is how I would expect it to work. With that one parse removes the space between name and lat (as expected) but it does not do the same between '.0' and Lon variable and I would expect it to work the same as before.

      Why does it remove the space before the 98 if there is a place holder (the .) after the variable? Is seem like it's scanning backwards from the literal '.0'.

      I always thought that the . worked the same as a variable but it does not seem to.

      • Rick McGuire

        Rick McGuire - 2008-05-13

        I'm not sure I understand your confusion. The placeholder period works precisely like a variable. There's no backwards scanning involved...the placeholders only function in the context of parsing up an individual segment of the string. The pattern

        Parse value Record with Name Lat'.0' Lon'.0' .

        Splits the string into 3 segments using the string pattern '0.'. Then, for each string segment, the variable assignment rules are applied using the variable list assignment rules. The first segment corresponds to the variable list "Name Lat", so Name will get the first blank delimited token of that segment, Lat will get the rest of the segment, with no stripping of blanks applied. The second segment gets the variable list "Lon" applied to it. Since Lon is the only variable in that list, it receives the entire string segment (no blank stripping at all). The third segment is the part after the second '.0'...its variable list is just the placeholder, so it's discarded. The placeholder is not really needed here, as that part would get discarded even without it.

        By adding the extra placeholders before the '.0' triggers, the blank token rules get applied to all of the real variables. For the first segment, Name and Lat are assigned the first and second blank delimited tokens and the placeholder consumes the rest of the string. Adding the '.' causes the blanks to be stripped for Lat. Same thing for the second segment. By using "Lon ." as the variable list, Lon now receives the blank delimited token, the placeholder consumes the rest of the string.

        These are all part of the standard Rexx parsing rules..and have been for almost 30 years now.


    • Rick McGuire

      Rick McGuire - 2008-05-07

      No, it shouldn't. When parse is assigning values to the list of variables in a segment, the last variable in the list receives the remainder of the string being parsed. Since you only have a single variable specified, those veriables receive everything, including the blanks. To get the blanks removed, use a ".' placeholder as the last variable

      Parse value Record with Name Lat . '.0' Lon . '.0'

      • William

        William - 2008-05-08

        I disagree with your solution.

        I did use a '.' as the last token on the parse line.
        "Parse value Record with Name Lat'.0' Lon'.0' . "

        • Rick McGuire

          Rick McGuire - 2008-05-08

          Yes, but you used the period where it doesn't have any effect on the result. The list of variables involved are the lists that lie between pairs of triggers that determine how the string gets split into pieces. This pattern

          Parse value Record with Name Lat'.0' Lon'.0' .

          Processes two lists of variables, "Name Lat" and "Lon". For the first list, the name Name gets the first blank-delimited token, the variable Lat gets the remainder of that string segment (" 45'). No leading or trailing blanks will be removed. For the second list, since "Lon" is the only (and hence last) variable in the list, it receives the entire string. To get the blanks stripped off, you need to extend both lists to use the dummy placeholder. The trailing "." on your template has no real effect and is unnecessary. You template needs to be

          Parse value Record with Name Lat . '.0' Lon . '.0'

          Now your lists of variables are "Name Lat ." and "Lon .". For the first, Name and Lat will be assigned to the first and second tokens, respectively, and the "." will consume the remainder of the string. For the second list, Lon will get the first token, and the "." will get the remainder.


Log in to post a comment.