To: Eli Zaretskii cc: djgpp AT delorie DOT com, dan AT verity DOT ICS DOT UCI DOT EDU Subject: Re: novice errors? dpmi, info, groff, df In-reply-to: Your message of "Tue, 18 Mar 1997 14:11:02 +0300." Date: Tue, 18 Mar 1997 17:23:22 -0800 From: Dan Hirschberg Message-ID: <9703181723.aa06452@paris.ics.uci.edu> > > But when I type: info groff > > I get an error message: Bad command or file name. > > Groff doesn't come with Info documentation, but with man pages. You With man.bat defined, man-type pages are now handled correctly; thanks. However, "info utils" generates an ungraceful error message. > > 3. df.exe seems unable to handle my large disk. > > It tells me that I have 999968 1024-blocks (adds up to 1G) > > and that I have used 0 of them, when I have 2G disk > > and I have about 1.3G free. > > df uses the library function `statfs' to report disk usage. `statfs' > uses function 36h of the DOS Int 21h to get that info. I suspect that > either the NT DOS box doesn't support that function completely, or it > has problems with large partitions such as yours. Could you please > write a short test program that calls `statfs' and prints the results, > test it on your machine and tell here what you see printed? I would I wrote the following program and ran it (and variant) as well as df. Here are the results: ******************* the program ************* #include #include #include extern int errno; main() { char *path = "a:/"; int i; struct statfs buf, *bufptr; bufptr = &buf; i = statfs(path,bufptr); if (i==0) { printf("SUCCESS\n"); printf("type=%d\n",bufptr->f_type); printf("bsize=%d\n",bufptr->f_bsize); printf("bfree=%d\n",bufptr->f_bfree); printf("bavail=%d\n",bufptr->f_bavail); printf("files=%d\n",bufptr->f_files); printf("ffree=%d\n",bufptr->f_ffree); } else { printf("FAILURE, returnval=%d, errno=%d\n",i,errno); } } ******************* running the program (looking at floppy disk) ******************* SUCCESS type=0 bsize=1024 bfree=263 bavail=263 files=713 free=263 ******************* running df a: ******************* Filesystem 1024-blocks Used Available Capacity Mounted on Drive A: 713 450 263 63% a:/ ******************* running ls -lsf a: ******************* total 450 8 -rw-r--r-- 1 dosuser dos 7186 Mar 13 18:10 cwsdpmi.doc 20 -rwxr-xr-x 1 dosuser dos 20217 Mar 13 18:10 cwsdpmi.exe* 226 -rwxr-xr-x 1 dosuser dos 230940 Mar 12 17:11 grader52.cof* 196 -rwxr-xr-x 1 dosuser dos 200192 Mar 13 18:12 grader52.exe* (The grader52.cof file was produced under djgpp 1.x and grader52.exe was produced under 2.01) ******************* changing a: to c: and running the program ******************* SUCCESS type=0 bsize=32768 bfree=31249 bavail=31249 files=31249 ffree=31249 ******************* running df c: ******************* c:/djgpp/bin/df: cannot find mount point for c: ******************* running df c:\ ******************* c:/djgpp/bin/df: cannot find mount point for c:\ ******************* running df c:/ ******************* c:/djgpp/bin/df: cannot find mount point for c:/ ******************* running df ******************* Filesystem 1024-blocks Used Available Capacity Mounted on Drive A: 713 450 263 63% a:/ c:\ 999968 0 999968 0% c:/ c:/djgpp/bin/df: d:/: No such device (ENODEV) c:/djgpp/bin/df: ?@: No such file or directory (ENODEV) c:/djgpp/bin/df: ??????????: No such file or directory (ENODEV) [where each ? stands for some graphical character] > > 4. groff works pretty well except that I got error messages > > that inform me of a problem in \djgpp\share\groff\tmac\tmac.ps > > Lines 52 and 53 of that file refer to files that have long filenames > > but the system seems not able to find them. > > When I replace the reference to tmac.pspic with the 8.3 compliant > > name (on my system, that turned out to be tmac~1.psp) > > that seemed to bandage the problem. > > That's because you unzipped the distribution in a way that munges the > long filenames by appending such numeric tails. You should use an > unzip program that truncates the names to 8+3 before handling them to > NT. InfoZip's UnZip is one such program, and it is free. Changing the filenames to be 8.3 compliant by truncation (such as moving tmac.pspic to tmac.psp ) makes everything work. Thanks. It seems to me (but I really am a novice, so don't pay too much attention) that the system ought to first look for a long name matching the given name (here, tmac.pspic) and, if it fails to find it, secondly look for the truncated name (here, tmac.psp). That would make the system consistent with an OS that has long names and also with an OS that has only 8.3 compliant names. Unzipping files that have long names should result in the long names being preserved because, first, other software may look for the long name and, second, there could easily be name conflicts if the original files have similar names (such as myprog.txt1 and myprog.txt2). Just a thought. Novice disclaimer repeated.