Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

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

May
12,834
163
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"]"
 
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.
 
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.
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:
If you don't want your filenames expanded, then either don't create such highly dubious (and impractical) filenames, or turn off nested variable expansion before calling PDIR.
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.
 
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?
 
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"]"
 
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?
 
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.
 
You are not surprised that IE is not compatible with command line utilities, be it CMD or TCC, do you?

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.
 
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.
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.
 
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"?
 

Similar threads

Back
Top