On 6/4/2024 11:34 PM, hms--- via Freedos-user wrote:
As per Tom's request, below is a short batch file to show the issue.
It appears that the DIR command prematurely terminates it's listing
without error if a directory bearing the same name is encountered.
As I understand it, the DIR command sho
As per Tom's request, below is a short batch file to show the issue.
It appears that the DIR command prematurely terminates it's listing
without error if a directory bearing the same name is encountered.
As I understand it, the DIR command should make no distinction between
file and directory na
Hi Eric
I think the issue is more complicated/ subtle than I first thought. If
you create the structure I showed, you will be able to reproduce the
problem. Two other FreeDos respondents were able to reproduce the
problem. I was perplexed as to why I could not find files that I knew
existed. I
Hi!
Not sure whether I can reproduce the problem...
If I have a directory with files 1.2, 3, 4.5 and 6,
DIR and DIR *.* shows all files and DIR * only shows
the files without extension: 3 and 6. DIR *. does
the same. So everything seems to work as expected?
Tested on FAT12, FAT16, FAT32 and D
Nope, not just FreeDos. I have tried about four flavours of DOS with the
same result. Same with XCOPY or XXCOPY with /L option. Almost like the
DIR and related utility programs "file matching code" share similar
source code. I know zero about DOS internals ;-) I just stumbled across
this issue
Nope, not just FreeDos. I have tried about four flavours of DOS with the
same result. Same with XCOPY or XXCOPY with /L option. Almost like the
DIR and related utility programs "file matching code" share similar
source code. I know zero about DOS internals ;-) I just stumbled across
this issue
On Mon, 03 Jun 2024 17:05:13 +0200, hms--- via Freedos-user wrote:
> The point I am trying to make is about the unexpected behaviour of the
> DIR command [...]
The sources are available, no? Fix it yourself?
I just tried it in Dosbox and it seems to stop even earlier, not
listing any deeper file
Actually, I'd say that's better behavior than I get from a command line
in windows 10.
When I create the structure you showed below, I do indeed get all the
files/directories (made them all directories except the .asm files),
then I get output equivalent to your first listing.
When I change
The point I am trying to make is about the unexpected behaviour of the
DIR command and that is if a directory exists with the same name as the
file one is searching for, the directory listing is terminated early
without error.
In my example, if the Q directory is renamed to Q4 and the command
Regardless of whether they're files or directories, if there is no file
extension, then don't put on the second star, just a *. will do the
search for you. By placing the second star, you're making the os search
for extensions by default. Leave it out, and it will search for just
files w/o th
Look at python for dos - http://www.caddit.net/pythond/
If it has the os module, I'll bet you could do it.
On Sun, Jun 2, 2024, at 11:19 PM, hms--- via Freedos-user wrote:
> Hi
> I am looking for files named Q and not directories named Q. In my case I
> have thousands of assembler text files wi
Hi
I am looking for files named Q and not directories named Q. In my case I
have thousands of assembler text files without filename extensions. It
comes from early days starting out with TSC Flex and Uniflex followed by
the Mark Williams Coherent operating systems.
John
On 2024/06/02 22:29, t
Don't know if it helps, but I've found that if you want *just*
directory names, and you don't have a directory program that allows you
to set flags, so it only shows directories, then the best way to get
them is to do something like:
dir *.
Since most directory names don't have extensions, t
13 matches
Mail list logo
