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

PDIR and descriptions

Discussion in 'Support' started by JohnQSmith, Oct 29, 2012.

  1. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    That alias is just about impossible to debug! Do you have a simplified version that displays the problem?
     
  3. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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!
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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 "..\..".)
     
  5. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    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.
     
  6. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  8. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    Same thing at home on a brand new install of TCMD on brand new install of 64 bit Windows 8.

    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 ---
    
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    "." 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?
     
  10. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    By that rationale, ".." is a valid filename for the parent directory as seen from the current directory.

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

    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.
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    ".." 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.
     
  12. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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?
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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 "..".
     
  15. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0

    FWIW, I see:

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

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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.

    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.
     
  17. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.)
     
  18. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    Thank you for offering assistance. Using a FOR loop never crossed my mind since that's why PDIR is 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.

    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
     
  19. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    PDIR is not intended to handle every possible case (particularly when using variable functions); that's why FOR and DO are there!

    In build 43, it works the same both ways.

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

    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.
     
  20. nikbackm

    Joined:
    May 30, 2008
    Messages:
    194
    Likes Received:
    1
    C:\Temp>*echo %@filename[..]
    ..

    C:\Temp>
     
  21. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Not relevant -- since you're not passing a pathname, that is interpreted as "*echo .."
     
  22. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    559
    Likes Received:
    7
    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
     

Share This Page