How to? "PDir" not working the way the I _thought _ the documentation said it does…

#1
Again, as using, using a “saved” TCC session transcript:
Code:
   Mon  Feb 27, 2012   3:00:55p
TCC  13.03.46   Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Registered to Daniel Mathews
[Z:\]cd PDirTests
[Z:\PDirTests]PDir * /(@Ext[*] fpn zc dy/m/d th:m:s)
txt Z:\PDirTests\A File.txt               0 2012/02/27 14:46:13
txt Z:\PDirTests\A Third File.txt               0 2012/02/27 14:46:31
txt Z:\PDirTests\And A Fifth File.txt               0 2012/02/27 14:47:04
txt Z:\PDirTests\Another File.txt               0 2012/02/27 14:46:19
txt Z:\PDirTests\Still Another File.txt               0 2012/02/27 14:46:41
This what one would expect and is OK, except for the fact that the individual fields are both separated by blanks and contain blanks, so there’s really no reliable way to “parse” the individual fields.

Next try:
Code:
[Z:\PDirTests]PDir * /([email protected][*] -40.40fpn zc dy/m/d th:m:s)
txt Z:\PDirTests\A File.txt                                0 2012/02/27 14:46:13
txt Z:\PDirTests\A Third File.txt                          0 2012/02/27 14:46:31
txt Z:\PDirTests\And A Fifth File.txt                      0 2012/02/27 14:47:04
txt Z:\PDirTests\Another File.txt                          0 2012/02/27 14:46:19
txt Z:\PDirTests\Still Another File.txt                    0 2012/02/27 14:46:41
This one also works as one would expect and the results are easily “parsable”. However, the output file is far larger than one might like it to be since it contains sometimes rather-long sequences of consecutive blanks. (In the "real world" case, these sequences of blanks could be well over 100 characters long.)

So, next try:
Code:
[Z:\PDirTests]PDir * /A-D /(@Ext[*]"*"fpn"*"zc"*dy/m/d"*"th:m:s)
txt"*"fpn"*"zc"*dy/m/d"*"th:m:s
txt"*"fpn"*"zc"*dy/m/d"*"th:m:s
txt"*"fpn"*"zc"*dy/m/d"*"th:m:s
txt"*"fpn"*"zc"*dy/m/d"*"th:m:s
txt"*"fpn"*"zc"*dy/m/d"*"th:m:s
This is not quite what I would expect given that the double quotes are retained the despite the fact that the documentation says “"..." Literal string (in quotes). Characters are displayed as is, except that escape characters are converted”, which I would at least think implied that the double quotes would be “stripped” (after all, who would want to see the double quotes in the output?).

So next try skipping the double quotes:
Code:
[Z:\PDirTests]PDir * /(@Ext[*]*fpn*zc*dy/m/d*th:m:s)
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
This is not only not what I want, but where did those "D41D8CD98F00B204E9800998ECF8427E" sequences come from?

So, on the way to what I’m really trying to accomplish:
Code:
[Z:\PDirTests]Set Var=*
[Z:\PDirTests]PDir * /A-D /(@Ext[*]"%Var"fpn"%Var"zc"%Var"dy/m/d"%Var"th:m:s)
txt"*"fpn"*"zc"*"dy/D41D8CD98F00B204E9800998ECF8427E/*14:46:13
txt"*"fpn"*"zc"*"dy/D41D8CD98F00B204E9800998ECF8427E/*14:46:31
txt"*"fpn"*"zc"*"dy/D41D8CD98F00B204E9800998ECF8427E/*14:47:04
txt"*"fpn"*"zc"*"dy/D41D8CD98F00B204E9800998ECF8427E/*14:46:19
txt"*"fpn"*"zc"*"dy/D41D8CD98F00B204E9800998ECF8427E/*14:46:41
The double-qoutes again, kind of what you would expect given the previous.

So, attempting to just remove the double quotes:
Code:
[Z:\PDirTests]PDir * /A-D /(@Ext[*]%Varfpn%Varzc%Vardy/m/d%Varth:m:s)
txtVarzc/D41D8CD98F00B204E9800998ECF8427E/02:s
txtVarzc/D41D8CD98F00B204E9800998ECF8427E/02:s
txtVarzc/D41D8CD98F00B204E9800998ECF8427E/02:s
txtVarzc/D41D8CD98F00B204E9800998ECF8427E/02:s
txtVarzc/D41D8CD98F00B204E9800998ECF8427E/02:s
What you really expect given that the there is nothing to delimit the variable name and the field names; and again, what are those "D41D8CD98F00B204E9800998ECF8427E" sequences?

So, next attempt using the way sequential variables are otherwise “separated” in TCC (with a trailing percent sign, as for cmd.exe, I believe):
Code:
[Z:\PDirTests]PDir * /A-D /(@Ext[*]%Var%fpn%Var%zc%Var%dy/m/d%Var%th:m:s)
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
txt*fpn*zc*dy/D41D8CD98F00B204E9800998ECF8427E/*th:02:s
Well, that didn’t work either (no particular surprise for now).

So that’s it for now. Is there any way I can “stick” the value of a variable into PDir’s output without the surrounding double quotes?

- Dan

 

rconn

Administrator
Staff member
May 14, 2008
10,551
97
#2
The "D41D8CD98F00B204E9800998ECF8427E" is the MD5 hash of the file -- which is what you asked for. (Inadvertently, by not including any delimiters in your formatting string -- so PDIR took the '/' in your date spec as the delimiter.)

Double quotes are not stripped (which is what the users requested when PDIR was created). It would also create a significant incompatibility with every other command (double quotes are never stripped).

I don't have any idea what variables you're trying to insert, and neither does the parser. (And you didn't specify how they were defined in your message -- but I certainly hope you're not wanting to use '*' as a variable, as it has another (overriding) meaning.) You're running everything together in one mishmash, so the parser is going to have to guess how to expand things. For example, this string:

%Var%fpn%Var%zc

will be interpreted as a request for the %Var% variable, followed by a literal "fpn" string, followed by another request for the %Var% variable, followed by another literal string "zc", etc. Maybe that's what you want, but it would be a lot safer and more reliable to use the %[] syntax instead.

Remember that variables will be expanded before PDIR is executed (as with almost every other command). You can execute variable functions while processing the PDIR format by specifying them with just the leading @ (no %).

Overall, your syntax is an incipient disaster -- if you expect the DWIM parser to automagically parse a long, delimiterless string into something meaningful -- well, you're apt to be disappointed.
 
#3
Thank you, Rex; but quite coincidentally, I, after much experimentation, just (as in less than a minute ago) got the thing to work precisely the way I wanted it to (by echoing the results of a "@Replace" function on the output of the "PDir" command as "captured" by a "Do ... /P" command). But I do take issue with the docs ("..." Literal string (in quotes). Characters are displayed as is, except that escape characters are converted.) on several points:

1. The quotes are not necessary.
2. The quotes, as far as I can tell, are essentially meaningless other than the fact that they are written directly to the output like essentially any other character that is not an "explicit" field-type character (and I haven't experimented with it as of this moment so I really don't know how you can echo characters like a "c", for instance).
3. The various "fields" in the format specification are blank (and possibly other white space) delimited; double quotes seem to have absolutely nothing to do with it.

While this is no longer an issue for me because I have solved my problem(s), the what (at least appears to me as) misleading documentation might cause problems for other people in the future.

And I really don't understand your comments about the asterisk in this situation. I chose it precisely because it could never appear in a valid file name, and since I have the code written and mostly tested it is, as far as I can tell at this point, working perfectly.

But thank your for at least getting back at me relatively quickly!

- Dan
 

rconn

Administrator
Staff member
May 14, 2008
10,551
97
#4
1. The quotes are not necessary.
The quotes definitely are necessary, if you want to use characters that would otherwise be interpreted as PDIR formatting characters.

2. The quotes, as far as I can tell, are essentially meaningless other than the fact that they are written directly to the output like essentially any other character that is not an "explicit" field-type character (and I haven't experimented with it as of this moment so I really don't know how you can echo characters like a "c", for instance).
Not true -- when PDIR encounters a double quote, it treats everything until a following double quote as a literal character.

3. The various "fields" in the format specification are blank (and possibly other white space) delimited; double quotes seem to have absolutely nothing to do with it.
?? I never said it did (nor does the help). The quotes are there to allow you to write any character(s) to the output without them being reinterpreted.
 
#5
I played with this a little. If you use unusual characters as quotes, you can isolate long file names.
Code:
v:\> PDir 500* /('fpn')
'V:\500meg'
 
v:\> PDir 500* /(!fpn!)
!V:\500meg!
You can even get backquotes if you try hard enough!

Code:
v:\> PDir *[ ]* /(^`fpn^`)
`V:\sysutils UNZIPPED`
`V:\397 006 raw.xlsx`
`V:\projects - shortcut.lnk`
`V:\spaces.txt  `
Is there any way possible (escape sequence, variable, ...) to get real double quotes around fpn?
 
#9
Guys, my real first goal was just to get a minimally-sized list of all of the files (possibly matching one or more patterns) in a directory and all of its subdirectories that can be easily parsed, where the "top" directory could be the root directory of a physical hard disk. ("Minimally-sized because these files would be most likely stored on my RAM disk, which is not all that small (402,632,704 bytes total disk space) but has a lot of stuff on it (75.5% in use). This is because, simply put, I start projects far faster than I finish them because of my bad memory and glacial slowness (hopefully one day in the not-too-distant future I will have "identified" all of the projects I that I want to do and therefore the project back-up will gradually dissipate), and one of the reasons I start new projects as they occur to me is so I have "evidence" of something that I want to accomplish and how I wanted to accomplish it because I'll forget both if I don't do that.​

And, Rex, this is kind of getting like arguing "how many angels can dance on the head of a pin". I think the bottom line here is that from my perspective it makes sense for the double quotes to be needed to enclose literal characters (such a "c"), however I would not have expected double quotes to be output if that is one of the primary reasons for their significance. And you say above, and I quote, "Double quotes are not stripped (which is what the users requested when PDIR was created)", but I have a more than two dozen "experiments" here where they absolutely are stripped in every case (in fact, at this moment I have not been able to come up with a scenario where they are not stripped) which I truly don't understand from what you say above and my own recollections about the matter. (I can zip them up and ship them to you if you don't really believe me.)

But the bottom line for me is that the need you felt to maintain 100% upward compatibility with cmd.exe's "language" (which, truth be told, is so limited as to not be really a "language" at all) has been a millstone around your neck and that of all of your end users. (I'm really not disagreeing with that decision since I really (believe it or not!) have no opinion on the matter; I'm just stating one of the major consequences of the path that you chose to take.) And I will add that, for me who has probably coded substantially in more than a dozen computer languages over more than 30 years, TCC's syntax is, by far, the worst I've ever encountered in every possible respect - although, again, that is a direct consequence of your desire to maintain strict upward compatibility with cmd.exe; and again I really have no opinion (believe it or not!) on the matter. (Just to "balance the coin" a little bit, TCC also has, by far, the most "powerful" computer language I've ever encountered in my more than 30 years of experience, and that far outweighs the absolutely horrible syntax millstone). And, in the case of "PDir" itself, I just have to "experiment" a little bit to get what I ultimately want, but so what?

I have to admit that the main reason I'm not just sending you the stuff I referred to above is because it was basically just a series of "random" experiments with no real "organization" and I really don't want to waste any more time on it if you are not interested, but if you are I would be quite willing to take the time to do that. Strictly your choice with no obligation on your part.

-- Dan