PDIR and descriptions

JohnQSmith · 2012-10-29

So, pizzaman really got me going with DESCRIBE trying to find an answer for his question. This is my third DESCRIBE post today because of it.

I really don't like the format of DIR /Z so I've been working on an alias to make a DIR look like the usual DIR except with descriptions included. Here's what I've got so far...

Code:

alias d=`pdir /(dy-m-d  th:m z  @if[%%@len[%%@descript[*]] gt 0,%%@if[%%@len[%%@filename[*]] ge 23,%%@left[21,%%@filename[*]]+  %%@descript[*],%%@filename[*]%%@repeat[ ,%%@max[0,%%@eval[25-%%@len[%%@filename[*]]]]]%%@descript[*]],%%@filename[*]]) /k /m /h /d`

and it works fine.

(here it comes...)

But, sometimes it doesn't show the ".." directory. I've been able to narrow down the problem to when TCC is showing an 8.3 representation of the folder I'm in.

HTML:

[C:\Documents and Settings\winuser\temp]
13:38:24 $ d
 
Volume in drive C is unlabeled      Serial number is 58b8:a853
Directory of  C:\Documents and Settings\winuser\temp\*
 
2012-10-29  13:34         <DIR>    .
2012-10-29  13:34         <DIR>    ..
2012-10-29  13:35              11  fileA.tmp                Description of FileA.tmp
2012-10-29  13:37              11  fileB.tmp
2012-10-29  13:36              11  fileC.tmp                Description of FileC.tmp
2012-10-29  13:37              11  fileD.tmp
2012-10-29  13:36              11  fileE.tmp                Description of FileE.tmp
2012-10-29  13:37              11  fileF.tmp
2012-10-29  12:28              13  ThisIsAnotherReallyLongFileName.txt
2012-10-29  13:38              13  ThisIsAReallyLongFile+   Description of ThisIsAReallyLongFileName.txt
                92 bytes in 8 files and 2 dirs    32,768 bytes allocated
    37,647,593,472 bytes free
 
[C:\Documents and Settings\winuser\temp]
13:38:25 $ cd ~/temp
 
[C:\Docume~1\winuser\temp]
13:40:59 $ d
 
Volume in drive C is unlabeled      Serial number is 58b8:a853
Directory of  C:\Docume~1\winuser\temp\*
 
2012-10-29  13:34         <DIR>    .
2012-10-29  13:34         <DIR>
2012-10-29  13:35              11  fileA.tmp                Description of FileA.tmp
2012-10-29  13:37              11  fileB.tmp
2012-10-29  13:36              11  fileC.tmp                Description of FileC.tmp
2012-10-29  13:37              11  fileD.tmp
2012-10-29  13:36              11  fileE.tmp                Description of FileE.tmp
2012-10-29  13:37              11  fileF.tmp
2012-10-29  12:28              13  ThisIsAnotherReallyLongFileName.txt
2012-10-29  13:38              13  ThisIsAReallyLongFile+   Description of ThisIsAReallyLongFileName.txt
                92 bytes in 8 files and 2 dirs    32,768 bytes allocated
    37,647,794,176 bytes free

rconn · 2012-10-29

That alias is just about impossible to debug! Do you have a simplified version that displays the problem?

JohnQSmith · 2012-10-30

rconn said:
Do you have a simplified version that displays the problem?

How about this?

Code:

pdir /(z @filename[*]) /h

Code:

[C:\Documents and Settings\winuser\temp]
09:20:22 $ pdir /(z @filename[*]) /h
        <DIR>   .
        <DIR>   ..
             11 fileA.tmp
             11 fileB.tmp
             11 fileC.tmp
             11 fileD.tmp
             11 fileE.tmp
             11 fileF.tmp
             13 ThisIsAnotherReallyLongFileName.txt
             13 ThisIsAReallyLongFileName.txt
 
[C:\Documents and Settings\winuser\temp]
09:20:33 $ cd ~/temp
 
[C:\Docume~1\winuser\temp]
09:20:59 $ pdir /(z @filename[*]) /h
        <DIR>   .
        <DIR>
             11 fileA.tmp
             11 fileB.tmp
             11 fileC.tmp
             11 fileD.tmp
             11 fileE.tmp
             11 fileF.tmp
             13 ThisIsAnotherReallyLongFileName.txt
             13 ThisIsAReallyLongFileName.txt

Edit: W00H00! Post #300!

rconn · 2012-10-30

WAD. (I see it happening in all cases, regardless of whether it's displaying the LFN or SFN directory.)

What's happening is that the @FILENAME function is looking for the last part of the string that isn't part of the path. What is sees is "@filename[c:\Docume~1\winuser\temp\..]" -- and there isn't any part of that string that isn't a path, so it returns an empty string. (".." is not a file name, it's a directory name, and @filename has to be able to deal with arguments like "d:.." and "..\..".)

Charles Dye · 2012-10-30

Glad to see that you have power and communications, and (presumably) a roof over your head. What we've been seeing on the news looks pretty awful.

JohnQSmith · 2012-10-31

rconn said:
WAD. (I see it happening in all cases, regardless of whether it's displaying the LFN or SFN directory.)

I get the double dots for LFN directory and not for SFN directory. I do understand your explanation about "@filename", but there is a discrepancy. See example here, and above in posts 1 and 3. (no plugins loaded)

HTML:

[C:\Documents and Settings\winuser\temp]
12:24:58 $ *pdir /(z @filename[*]) /h
        <DIR>  .
        <DIR>  ..
            13 ThisIsReallyLongFilenameNumberOne.txt
            13 ThisIsReallyLongFilenameNumberTwo.txt
 
[C:\Documents and Settings\winuser\temp]
12:25:02 $ ver /r
 
TCC  14.02.41  Windows XP [Version 5.1.2600]
TCC Build 41  Windows XP Build 2600  Service Pack 3
Registered to *********** - 1 System License

rconn · 2012-10-31

Not reproducible here (Win 7, x64). It should *never* display ".."; if it does for you, that would be the bug, not displaying it is correct.

JohnQSmith · 2012-10-31

Same thing at home on a brand new install of TCMD on brand new install of 64 bit Windows 8.

rconn said:
Not reproducible here (Win 7, x64). It should *never* display ".."; if it does for you, that would be the bug, not displaying it is correct.

It doesn't matter to me which way is correct (I can modify the alias in post 1 to fit either), as long as it's consistent. Also, if ".." is supposed to be hidden, then "." should be hidden too.

HTML:

[C:\Program Files\JPSoft\TCMD14x64]ver /r
 
TCC  14.02.42 x64   Windows 8 [Version 6.2.9200]
TCC Build 42   Windows 8 Build 9200
Registered to *********** - 1 System License
 
[C:\Program Files\JPSoft\TCMD14x64]alias
TCC: No aliases defined
 
[C:\Program Files\JPSoft\TCMD14x64]function
TCC: No functions defined
 
[C:\Program Files\JPSoft\TCMD14x64]plugin
TCC: No plugins loaded
 
[C:\Program Files\JPSoft\TCMD14x64]*pdir /(z @filename[*]) /h
        <DIR>   .
        <DIR>   ..
          34304 BorlndMM.dll
         621720 English.dll
         407192 EnglishD.dll
--- snip ---
 
[C:\progra~1\jpsoft\tcmd14~1]*pdir /(z @filename[*]) /h
        <DIR>   .
        <DIR>
          34304 BorlndMM.dll
         621720 English.dll
         407192 EnglishD.dll
--- snip ---

rconn · 2012-10-31

JohnQSmith said:
Also, if ".." is supposed to be hidden, then "." should be hidden too.

"." is a valid filename for the current directory, ".." is not.

I am curious about one thing, though -- most people spend their time try to get rid of "." and ".." -- why are you going to such lengths to display them?

JohnQSmith · 2012-10-31

rconn said:
"." is a valid filename for the current directory, ".." is not.

By that rationale, ".." is a valid filename for the parent directory as seen from the current directory.

rconn said:
I am curious about one thing, though -- most people spend their time try to get rid of "." and ".." -- why are you going to such lengths to display them?

I'll answer that with a quote from post 1 above with emphasis added.

JohnQSmith said:
I really don't like the format of DIR /Z so I've been working on an alias to make a DIR look like the usual DIR except with descriptions included.

Basically, it comes from coding for the web. By seeing the "." and "..", it reminds me to reference other files (images, css, links, etc.) with a leading "./" or "../" in relation to the current file to prevent accidental references to the root folder. I find myself catching other people making mistakes like that all the time when I parse web logs for 404 errors. (This is a big reason for my fondness for documenting the TPIPE command.) As examples, they'll link something incorrectly like "/js/jquery.js" instead of to correct locations such as "../css/styles.css" or "./images/head.png". I have to catch that crap and point it out to them and having the correct path handy for reference allows me to give them an "Aha!" moment.

rconn · 2012-10-31

JohnQSmith said:
By that rationale, ".." is a valid filename for the parent directory as seen from the current directory.

".." is an invalid filename for the current directory, which is what @filename is returning. If you want valid names for the parent directory, use @path.

Your complaint here seems to be that something that should never work occasionally does work (at least on your system, though I've been unable to reproduce it on three systems here). I believe that constitutes an isolated peculiarity, but not a bug.

JohnQSmith · 2012-10-31

rconn said:
... at least on your system

Systems. Plural. More than one system. Two different operating systems; one 32 bit and one 64 bit, one over 10 years old with no admin rights and one less than a week old (general release) with whatever admin rights UAC will let me have. Two different machines; one at work with dual Xeon processors and I'm guessing an Intel chipset and one machine at home with an Intel QX6700 processor and an nVidia chipset.

Anyone else seeing this or am I alone with this isolated peculiarity?

rconn · 2012-10-31

I really don't know what you want here -- @FILENAME will never, ever, be changed to return ".." as a filename, as this would break about a bajillion existing batch files. So at best, you're using something that you shouldn't be using, which inexplicably on your system sometimes almost works, but isn't supposed to. That doesn't seem like a good long-term solution, since if I am ever able to reproduce the problem, I will ensure that it never works on any system.

rconn · 2012-10-31

You do realize that :

Code:

pdir /(z @filename[*]) /h

is functionally equivalent to:

Code:

pdir /(z fn) /h

Except that @filename introduces a lot more overhead, and it cannot handle pathnames like "..".

K_Meinhard · 2012-11-01

JohnQSmith said:
Systems. Plural. More than one system. Two different operating systems; one 32 bit and one 64 bit, one over 10 years old with no admin rights and one less than a week old (general release) with whatever admin rights UAC will let me have. Two different machines; one at work with dual Xeon processors and I'm guessing an Intel chipset and one machine at home with an Intel QX6700 processor and an nVidia chipset.

Anyone else seeing this or am I alone with this isolated peculiarity?

FWIW, I see:

[C:\Program Files\JPSoft\TCMD14x64]*pdir /(z @filename[*]) /h
<DIR> .
<DIR> ..
34304 BorlndMM.dll
621720 English.dll
407192 EnglishD.dll

JohnQSmith · 2012-11-01

I'm not trying to start WWIII here, I'm just pointing out that I (and at least one other person) am seeing different output for LFN vs SFN directories. As a developer, if someone pointed out a possible error in my processing, I'd try to fix it before it bit me in the ass in the future instead of, once again, blaming the user.

Differing output from the same function with basically the same input raises a flag.

rconn said:
You do realize that :

Code:

pdir /(z @filename[*]) /h

is functionally equivalent to:

Code:

pdir /(z fn) /h

Except that @filename introduces a lot more overhead, and it cannot handle pathnames like "..".

If I could use "fn" in the alias (see above in post 1, the original reason for this whole line of discussion) instead of @filename, I'd jump on that like a duck on a junebug.

rconn · 2012-11-01

I'm still unclear exactly what you want here; you seem to be enthusiastically arguing both sides!

After trying three more systems, I found one that returned ".." from @filename. It turned out to not be an issue with @filename per se, but rather an obscure combination of factors resulting in PDIR passing an unexpected string to @filename. I've added a fix to PDIR in build 43 so that @filename[*] will always return an empty string (as it should) when passed "..".

I looked at your original PDIR example; it seems that you're trying really hard not to use the PDIR format specifiers ([-]i.a) so that you can use the much longer, slower, clumsier, and obscure @filename / @left / @repeat etc. syntax instead. If you're determined to use variable functions (especially in combination with @filename), I'd recommend using FOR instead of PDIR. (DO won't work because it doesn't return "." and ".." -- the result of demands by everybody else to not show those entries.)

For example:

Code:

for %f in (*) do echo %@format[10,%@filesize[%f]] %@format[-30,%f] %@descript[%f]

(Add the appropriate additional fields and formatting to get your desired output.)

JohnQSmith · 2012-11-01

Thank you for offering assistance. Using a FOR loop never crossed my mind since that's why PDIR is there.

rconn said:
I'm still unclear exactly what you want here; you seem to be enthusiastically arguing both sides!

I am wanting consistency. I agree with you; I am arguing both sides since I don't care which way it works just as long as it works the same both ways.

My whole convoluted @IF statement was designed to take into account how long filenames were and whether or not they had descriptions.

Determine filename length (@LEN, @EVAL, @MAX). Since I'm only calculating the length once for the filler space in next bullet, I have to use @MAX to prevent a negative number being passed to @REPEAT.
If a name is shorter than a defined length, then print the name and fill in with spaces (@REPEAT) after it so the description (if it exists) will display at the desired position.
If a name is longer than a defined length, then truncate the name (@LEFT) and print the description (if it exists) at the desired position.

I still have to disagree with you on one point -- "." is not a filename, it is a directory name (or shortcut representation of a directory name). Why else would there be a "<DIR>" next to it? Also if it was a filename I would be able to do something like...

HTML:

[C:\temp]echo test > .
TCC: (Sys) Access is denied.
 "C:\temp"

... and not end up with an error pointing me to a directory.
I was just finished with this message and about to press Post Reply when I tried one more thing.
Would you explain the following to me in relation to files vs. directories and how @FILENAME works?

HTML:

[C:\temp]md subdir1
[C:\temp]echo > file1
[C:\temp]dir
 Volume in drive C is unlabeled      Serial number is b23a:439a
 Directory of  C:\temp\*
11/01/2012  21:44         <DIR>    .
11/01/2012  21:44         <DIR>    ..
11/01/2012  21:43         <DIR>    subdir1
11/01/2012  21:44              13  file1
                13 bytes in 1 file and 3 dirs    4,096 bytes allocated
   358,701,645,824 bytes free
[C:\temp]*pdir /(z @filename[*]) /h
        <DIR>   .
        <DIR>
        <DIR>   subdir1
             13 file1
[C:\temp]echo %@filename[c:\temp\subdir1]
subdir1

rconn · 2012-11-01

JohnQSmith said:
Thank you for offering assistance. Using a FOR loop never crossed my mind since that's why PDIR is there.

PDIR is not intended to handle every possible case (particularly when using variable functions); that's why FOR and DO are there!

I am wanting consistency. I agree with you; I am arguing both sides since I don't care which way it works just as long as it works the same both ways.

In build 43, it works the same both ways.

My whole convoluted @IF statement was designed to take into account how long filenames were and whether or not they had descriptions.

Did you ever try it with the format specifiers? That's why they are there! (It will also be far faster than the variable functions.)

I still have to disagree with you on one point -- "." is not a filename, it is a directory name (or shortcut representation of a directory name).

"." is a (virtual) object in the current directory. ".." is a (virtual) object in a different (parent) directory.

@FILENAME absolutely, positively, definitely, will never, ever, ever, ever return a "..", now or at any future date. It would break more batch files than you can count, and it would also demolish several hundred internal functions in TCC and Take Command that use it internally. It would make it impossible to use syntax like "..\.." or "....". There is no optional behavior or configuration here; it cannot do what you want without wrecking the remainder of TCC. If you want a variable function that returns a "..", do not use @FILENAME. If you're fixated on (mis)using PDIR with (way too many) variable functions, create a UDF.

Would you explain the following to me in relation to files vs. directories and how @FILENAME works?

I have no idea what you're looking for here. @FILENAME returns the last part of a name, scanning backwards until it finds a \ or /. If the next two characters to the right of a \ or / are "..", it skips those and returns the remaining characters.

Would it make you happy and solve all of your problems if @FILENAME[.] also returned an empty string? I can add a kludge for that if you want.

nikbackm · 2012-11-02

rconn said:
@FILENAME absolutely, positively, definitely, will never, ever, ever, ever return a "..", now or at any future date.

C:\Temp>*echo %@filename[..]
..

C:\Temp>

rconn · 2012-11-02

nikbackm said:
C:\Temp>*echo %@filename[..]
..

C:\Temp>

Not relevant -- since you're not passing a pathname, that is interpreted as "*echo .."

JohnQSmith · 2012-11-02

rconn said:
Did you ever try it with the format specifiers? That's why they are there! (It will also be far faster than the variable functions.)

You actually had me questioning myself for a minute. I asked myself, "why the hell did I stir the pot when I could have just done it that way?" Then I reworked it and remembered that I had been down that road before when I hit the same stumbling block.

Using the format specifiers works fine, except in the case where there is no description and the filename is longer than the maximum field width. If that's the case, I want the full name shown. That's why I was testing for the existence of descriptions. Comparison is shown below.

Code:

[C:\Docume~1\winuser\temp]
14:11:13 $ d
 
 Volume in drive C is unlabeled      Serial number is 58b8:a853
 Directory of  C:\Docume~1\winuser\temp\*
 
2012-11-02  13:37         <DIR>    .
2012-11-02  13:37         <DIR>
2012-11-02  13:36              13  file1.txt
2012-11-02  13:39              13  file2.txt              : Description of file2.txt
2012-10-31  12:24              13  ThisIsReallyLongFilenameNumberOne.txt
2012-11-02  13:38              13  ThisIsReallyLongFilen+ : Description of ThisIsReallyLongFilenameNumberTwo.txt
                52 bytes in 4 files and 2 dirs    16,384 bytes allocated
    37,315,555,328 bytes free
 
[C:\Docume~1\winuser\temp]
14:11:15 $ pdir /(dy-m-d  th:m z  -22.22fn   i) /k /m /h /d *
 
 Volume in drive C is unlabeled      Serial number is 58b8:a853
 Directory of  C:\Docume~1\winuser\temp\*
 
2012-11-02  13:37         <DIR>    .
2012-11-02  13:37         <DIR>    ..
2012-11-02  13:36              13  file1.txt
2012-11-02  13:39              13  file2.txt                Description of file2.txt
2012-10-31  12:24              13  ThisIsReallyLongFilena
2012-11-02  13:38              13  ThisIsReallyLongFilena   Description of ThisIsReallyLongFilenameNumberTwo.txt
                52 bytes in 4 files and 2 dirs    16,384 bytes allocated
    37,315,555,328 bytes free

Search

Welcome!

PDIR and descriptions

JohnQSmith

rconn

Administrator

JohnQSmith

rconn

Administrator

Charles Dye

Super Moderator

JohnQSmith

rconn

Administrator

JohnQSmith

rconn

Administrator

JohnQSmith

rconn

Administrator

JohnQSmith

rconn

Administrator

rconn

Administrator

K_Meinhard

JohnQSmith

rconn

Administrator

JohnQSmith

rconn

Administrator

nikbackm

rconn

Administrator

JohnQSmith