1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WAD Nested variable expansion in PDIR's @function[*]?

Discussion in 'Support' started by vefatica, Mar 10, 2014.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    SETDOS /X-4 makes this possible(note that the filename contains '%'):
    Code:
    c:\users\vefatica\appdata\local\microsoft\windows\temporary internet files\content.ie5\w2k0d1cw>
    setdos /x-4 & do f in *Lasda* (echo %f^n%@inode[%f]) & setdos /x+4
    %7bde374417-0d84-422b-b6c5-268c52b40889%7d_23145-Lasda-5806[1].jpg
    00B70000:000121AC
    
    How can I get that info with PDIR /(@inode[*])? SETDOS /X-4 fails to stop the nested expansion.
    Code:
    c:\users\vefatica\appdata\local\microsoft\windows\temporary internet files\content.ie5\w2k0d1cw>
    setdos /x-4 & pdir /(f @inode[*]) *Lasda* & setdos /x+4
    
    TCC: (Sys) The system cannot find the file specified.
     "%@inode["C:\Users\vefatica\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\W2K0D1CW\-0d84-422b-b6c5-268c52b40889-Lasda-5806[1].jpg"]"
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    WAD -- PDIR isn't doing nested variable expansion. PDIR substitutes the filename for the *, and expands the variable "%@inode[filename]". When the variable expansion routine processes the variable function, it looks for variables in the arguments and substitutes those as well. This is *not* nested variable expansion -- that would be if the variable contained another variable.
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    1. In http://jpsoft.com/forums/threads/pdir-files-with-percent-sign-in-name-cause-not-listing-other-files-in-directory.4016/ (which deals precisely with '%' in file names in @FUNCTION[*] in PDIR (but with a different gripe)), you said:
    That's what made me think it wasn't working correctly. What did you mean by that?
    2. How do I get around the problem? There are more such files on my system drive. I didn't name them; Microsoft did.
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Vince:
    I have not been able to figure out what you had tried to do above, because of the length of line. You could just map - temporarily - to a single letter, whether by SUBST or NET USE or otherwise, so you would not have to break lines. Likewise, a single long line of code requires horizontal scrolling, not visible at once, while a batch file makes it easier to read. Only the logistics of posting, not the substance, and there may be cases when the "one-liner" is the substance.

    I've been using PDIR for years without problems, including the @inode[*] function, never bothering in years with the "expansion" feature (setdos /x). I cannot translate the tongue in cheek to a real example. Most of the time I just use the format with the implied percent sign (%); only on rare occasion do I need to double the percent sign, usually for nested functions.

    Can you give a real example of a file name that includes a percent sign?
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    Here it is with a SUBST. In the first example, the file name is correct. In the second example, "%7bde374417" and "%7d_23145" were expanded to empty strings.
    Code:
    o:\> setdos /x-4 & do f in *Lasda* ( echo %f^n%@inode[%f] ) & setdos /x+4
    %7bde374417-0d84-422b-b6c5-268c52b40889%7d_23145-Lasda-5806[1].jpg
    00B70000:000121AC
    
    o:\> setdos /x-4 & pdir /(fn"^n"@inode[*]) *Lasda* & setdos /x+4
    TCC: (Sys) The system cannot find the file specified.
    "%@inode["O:\-0d84-422b-b6c5-268c52b40889-Lasda-5806[1].jpg"]"
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    I see the difference. Unfortunately I cannot think of any universal method that can relieve the pain of software intentionally shooting its own foot. Your own plug-in?
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    I don't get the plug-in remark?
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    I count 121 of them in C:\Windows\System32\winevt\Logs\.

    My first example was "real". It is a file in IE's cache.
     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    You are not surprised that IE is not compatible with command line utilities, be it CMD or TCC, do you?

    I suggested that while universal method dies not exist, you could write a plug-in to handle this specific style of abomination. and do some of the processing as strings, and report both the file name (unparsed) as well as its inode.
     
  10. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,299
    Likes Received:
    39
    Much though I love to slam IE, this style of hex-encoding is actually enshrined in standard: RFC 1738, and possibly others. It's vile, from a command-line standpoint, but we're stuck with it.
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    In that case does the RFC actually provide an unambiguous interpretation?
     
  12. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    It's time to upgrade the language to strictly separate code and data... where Fortran was in te 1960-s, and C in 1990.
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    Well I can't rewrite PDIR. And there's nothing special about @INODE. There's something unfortunate about how PDIR handles @FUNCTION[*]. It replaces '*' with the filename and sends the result off to the parser. Being on the inside, that filename is going to get evaluated first, and variables will be expanded (unless you've turned off all variable expansion, which would kill the expanding of @FUNCTION). You can't even doctor the string (say with @replace[%%,%%%%,*]) because '*' is expanded before @replace.
    I suppose TCC could internally doctor the filename (doubling the %s) but I'm not sure that'd work well and I suppose it'd take significant time. I also suppose TCC could, internally, use a variable with the actual file name in it ... replace '*' with %_PDIR_FILE_NAME ... so that SETDOS /X-4 would keep the actual file name from being parsed.
     
  14. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Should FEEDBACK be used to request that file names matching RFC 1738 (and its likes) be accepted as "atomic symbols", not subject to "variable expansion"?
     

Share This Page