dir /h error in empty directory

[thorsten]

Latest TCC

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

> *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.

 

[Charles Dye]

The error means that the system cannot find the given file.

What did you expect to see?

 

[thorsten]

What did you expect to see?

> *dir /h
0 bytes in 0 files and 0 dirs
33,000,390,656 bytes free

 

[Steve Fabian]

Try DIR /H /NE

 

[thorsten]

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 *)

 

[Charles Dye]

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 *)

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.

 

[Steve Fabian]

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.

 

[Charles Dye]

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.

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 *[.]*

 

[Charles Dye]

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.

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.

 

[thorsten]

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

 

[Steve Fabian]

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 *[.]*

Seems you can teach a new trick to an old dog...

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.

Yes, that's correct. DIR does not attempt to read files, so it cannot detect any other kinds of error.

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

Isn't that your observation?

 

[rconn]

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 *)

WAD -- TCC is designed for compatibility with CMD (whose DIR behaves exactly the same), not Bash.

 

[thorsten]

WAD -- TCC is designed for compatibility with CMD (whose DIR behaves exactly the same), not Bash.

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.

 

[Charles Dye]

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.

It's exactly the same in CMD:

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.

 

[thorsten]

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

 

[Charles Dye]

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

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.

 

[thorsten]

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.

 

[Steve Fabian]

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.

 

[Charles Dye]

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.

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?

 

[Charles Dye]

As the OP complained, the /H and the /NE actions ought to be independent.

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.

 

[thorsten]

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.

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?

 

[Charles Dye]

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?

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.

 

[Steve Fabian]

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.

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