dir /h error in empty directory

Aug 16, 2008
124
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.
 
Aug 16, 2008
124
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 *)
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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.
 
Aug 16, 2008
124
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.")
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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

Administrator
Staff member
May 14, 2008
12,340
149
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.
 
Aug 16, 2008
124
0
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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:

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.
 
Aug 16, 2008
124
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")
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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.
 
Aug 16, 2008
124
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.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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.
 
Aug 16, 2008
124
0
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

Super Moderator
Staff member
May 20, 2008
4,446
88
Albuquerque, NM
prospero.unm.edu
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.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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...
 
Similar threads
Thread starter Title Forum Replies Date
D How to? Suppress error message with dir /h and no files? Support 2
B DIR /Z Causes Application Error In At Least One Directory Support 4
E Fixed Bug with DIR /Z displaying descriptions Support 8
J Paths shown in DIR /B Support 2
K Fixed Prompt display will be shifted after use dir to display a filename with Chinese. (v25.00.28 x64) Support 18
Jesse Heines How to? How to display picture creation date with dir command Support 6
vefatica WAD DIR.BTM? Support 11
DrusTheAxe DIR reports meaningless SYMLINK information Support 14
C show file description? with dir? Support 8
vefatica DIR /F and streams? Support 7
rps Multi-column DIR /v not displaying all files. Support 5
R How to? Dir specific file search patterns with spaces in the pathnames? Support 6
rps Dir /Nfv -> Alt-F2 Support 2
rps @FILESIZE[....,a] allocated size not matching Dir results Support 8
A TCMD - Dir Command puts out blank lines? Support 16
S Problems with dir command in the debugger Support 5
M TCC incorrect dir output since Windows 1803 Support 6
x13 Problem listing repository files using DIR http(s)://... Support 8
cxxl dir /s works in mysterious ways :( Support 4
vefatica Help nit (FFIND and DIR with /S) Support 0
N Fixed Strange dir behavior Support 6
JohnQSmith Weird DIR output (missing lines) Support 1
C 7zip with date range .vs. filelist created with dir and daterange Support 0
D Towards shared (dir-)history lists Support 3
vefatica WAD DIR /HL still gets names wrong Support 16
vefatica DIR /S /HL? Support 4
H Fixed DIR /G returns wrong sizes Support 2
nickles WAD dir.htm Support 2
vefatica DO dir in /s /a:+d /d"g:\" * ( ... ) Support 26
vefatica DIR \\.\...? Support 4
M Fixed DIR /S /B1 ignores "/S" Support 5
C tcmd.ini not loading from program dir? Support 5
D Fixed Dir /Nm:n has changed Support 1
rps How to? dir /s unexpected results Support 10
vefatica Update to current install dir? Support 8
cgunhouse Problem with "dir /=" Support 4
P WAD TC 15.0.1.58 x64 crasches with a simple dir command Support 18
CWBillow dir /4 strange Support 2
samintz WAD DIR /B1 and /X Support 2
nickles dir behaves inconsistently Support 5
vefatica DIR, streams, and wildcards? Support 1
vefatica DIR /: /u ... streams not counted? Support 7
vefatica Documentation DIR /B /S /: Support 2
samintz How to? DIR listing for exact match Support 1
dcantor WAD dir "ftp:// ..." fails in TCC 15 Support 7
T How to? dir/pdir - 2nd level down only Support 7
MikeBaas How to? DIR: supress extensions? Support 5
old coot dir /s dies on my C: drive Support 2
A WAD Dir daterange + multiple path wildcards crashes tcc Support 2
old coot TC DIR command has trouble on my SSD Support 2

Similar threads