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

dir /h error in empty directory

Discussion in 'Support' started by thorsten, Mar 4, 2014.

  1. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    Latest TCC

    Using the /h switch ("Suppress the display of the "." and ".." directories") in an empty directory results in:

    Code:
    > *dir /h
    TCC: (Sys) Das System kann die angegebene Datei nicht finden.
    "F:\PortableApps\TextadeptPortable\Data\.textadept\modules\*"
    0 bytes in 0 files and 0 dirs
    33,000,390,656 bytes free
    The error means that the system cannot find the given file.
     
  2. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    What did you expect to see?
     
  3. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    Code:
    > *dir /h
    0 bytes in 0 files and 0 dirs
    33,000,390,656 bytes free
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Try DIR /H /NE
     
  5. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    Thanks, but that would also disable a - legitimate - error in case I requested globbing/matching:
    "dir *.*" should result in a error when the directory is empty, "dir" not. That's also consistent with the way Linux shells work (ls vs ls *)
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    I think that's a distinction without a difference; DIR means the same as DIR *

    CMD.EXE's DIR also gives a file-not-found error when nothing matches.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    The /NE option of DIR and many other commands basically suppresses warnings, not actual errors. A true error is one which has serious effects, e.g., a file which exists, but cannot be read due to data errors.

    As Charles wrote, DIR and DIR * are equivalent. DIR *.* is different - the former two match all files, the last only files that include a period.

    If you want the report as in your earlier post, use the /NE option. If you want an empty directory to report an error, don't use /NE. You cannot mix the two kinds of reports in a single command.

    BTW, *nix ls and ls * functions very differently from either CMD or TCC.
     
  8. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    They really should be different, but they ain't. Rex has apparently added a kludge to support this deeply ingrained MS-DOSism. If you want to match only filenames containing a period, you can use *[.]*
     
  9. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Looking at the help page for DIR, it seems as if the only error message that /NE suppresses is the file-not-found error. So I think this is exactly what Thorsten wanted.
     
  10. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    if "dir /h" reports a "file not found" then "dir" should also report that error because /h simply filters the output ("
    Suppress the display of the "." and ".." directories.")
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Seems you can teach a new trick to an old dog...
    Yes, that's correct. DIR does not attempt to read files, so it cannot detect any other kinds of error.
    Isn't that your observation?
     
  12. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    WAD -- TCC is designed for compatibility with CMD (whose DIR behaves exactly the same), not Bash.
     
  13. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    The point I was trying to make is that the behaviour is inconsistent. DIR in an empty directory does not give an error - so why should "DIR /h"?. Cmd does not have a "/h" so it's not a compatibility issue.
     
  14. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    It's exactly the same in CMD:

    Code:
    C:\>ver
    
    Microsoft Windows XP [Version 5.1.2600]
    
    C:\>dir u:\
     Volume in drive U is BACKUP
     Volume Serial Number is B81C-037F
    
     Directory of u:\
    
    File Not Found
    
    C:\>md u:\foo
    
    C:\>dir u:\foo
     Volume in drive U is BACKUP
     Volume Serial Number is B81C-037F
    
     Directory of u:\foo
    
    03/05/2014  08:02 AM  <DIR>  .
    03/05/2014  08:02 AM  <DIR>  ..
      0 File(s)  0 bytes
      2 Dir(s)  7,982,915,584 bytes free
    
    C:\>
    
    If the fules are listed, then something was found, so no file-not-found error. "File not found" includes both files and directories, despite the wording.
     
  15. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    Charles, you're missing the point. The point is:
    - dir in empty directory in CMD: no error, no "file not found"
    - dir in empty directory in TCC: no error, no "file not found"
    - dir /h in empty directory in TCC: "file not found" error

    "dir /h" is a TCC specific option and it should do exactly what it says in the help: "Suppress the display of the "." and ".." directories". Instead it additionally causes an error ("file not found")
     
  16. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Take a look at the screen capture I posted above; that's from CMD. CMD does give a file-not-found error when it doesn't find anything. The behavior is exactly the same: if anything is found, list it; if nothing is found, give a file-not-found error. /H just gives you one more way to exclude a couple of items which might otherwise be found.

    I think maybe you're getting hung up on this idea of an "empty" directory. (If the . and .. entries are present, is it really empty?) Whether the directory is empty or not is irrelevant. That error message means that no matching items (file or subdirectories) were found. You can get it in a directory containing a thousand files, if none of them matches your filespec or other filters.
     
  17. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    I'm pretty much aware of all of this. It just doesn't match what "/h" is supposed to do. /h is supposed to "hide dots". If /h would just take the output of dir and do exactly what the help says then it would be fine. But it causes an additional error. That's ugly, unnecessary and inconsistent.

    dir /K ("Suppress the header (disk and directory name) display") does exactly what it says it does
    dir /M ("Suppress the footer (file and byte count totals) display") does exactly what it says it does
    dir /h ("Suppress the display of the "." and "..") does not do what it says it does

    You see a pattern here? Yes, it's about the semantics of "suppressing" and it's inconsistent.
     
  18. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Ah, once I actually tried to perform the issue the OP complained of, I discovered that he is correct. All tests performed with *DIR so that aliases would not be used. I created an empty directory, and made it the CWD. When executing *DIR or *DIR * it reports

    Volume in drive C is Laptop160GiB Serial number is 001b:9a6b
    Directory of C:\TMP\z\*

    2014-03-05 11:44 <DIR> .
    2014-03-05 11:44 <DIR> ..
    0 bytes in 0 files and 2 dirs
    129,725,452,288 bytes free


    When I change it to *DIR /H * - or without the wikdcard - there is an error reported:


    Volume in drive C is Laptop160GiB Serial number is 001b:9a6b
    TCC: (Sys) The system cannot find the file specified.
    "C:\TMP\z\*"
    0 bytes in 0 files and 0 dirs
    129,725,452,288 bytes free


    As the OP complained, the /H and the /NE actions ought to be independent. BTW, the problem occurs in all versions of 4nt and TCC going back to Version 5. Om ny systems the /NE option hides the problem.
     
  19. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Are you saying that /H doesn't suppress the . and .. entries? I'd like to see an example of that.

    Or are you saying that "suppress" should mean something different from "not match"? Yes, /H can trigger a file-not-found error when it prevents DIR from finding the only items otherwise available to be found. Again, this is the same behavior as CMD.EXE. You can see the same effect with other options, e.g. /A-D (which CMD.EXE does support). Does DIR /A-D in an "empty" directory behave differently for you in TCC vs. CMD?
     
  20. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    They are independent; one hides fules, the other suppresses a file-not-found error. He's saying that the one should automatically imply the other. Personally, I don't see why /H should be different from every other range option in this regard.
     
  21. thorsten

    Joined:
    Aug 16, 2008
    Messages:
    124
    Likes Received:
    0
    I guess "suppress the footer" means something different than "don't match the footer"; I guess "suppress the header" means something different than "don't match the header" and yes, I guess, "suppress the dots" means something different than "don't match the dots". Would make sense, wouldn't it?
     
  22. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Not really, no; the header and footer are not items to be found. To "suppress" the header or footer would mean more like "don't generate". So the same word is used with slightly different implications on the same page.

    On the subject of fules and footers, . and .. are also included in the total number of directories listed in the footer. If you want to argue that that's horribly wrong behavior that should be fixed, I would have to agree with you. The directory counts given at the end of DIR /S can be wildly inaccurate, unless you also specify /H. I personally hate this behavior. But once again, it's the way CMD.EXE works so we're kind of stuck with it.
     
  23. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Actually I have rethought the issue, and on reconsideration the current operation is correct. Let's assume the case I reported, i.e., there is an empty directory. When DIR * is used, there are two subdirectories reported: . and ..; in other words, there are two entries found. However, *DIR /H * finds no entries in the directory, thus it correctly reports in the absence of the /NE option:
    TCC: (Sys) The system cannot find the file specified.
    "C:\TMP\z\*"

    Understanding is a bIt convoluted...
     

Share This Page