Maurice Lombardi wrote:

Hi all I have found a couple of small bugs in the last beta gpc-19990118.i386-pc-djgppv201.zip when using LFN=n 8.3 limitation in DOS 6.2

The problem comes from the fact that in this situation DOS makes uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an odd behavior displayed by the following short program:

program ff; uses dos; var F:SearchRec; begin FindFirst('ff.pas',Anyfile,F); writeln('l ',DosError); FindFirst('FF.PAS',Anyfile,F); writeln('u ',DosError); end.

DJGPP answers l 0 u 18 i.e. it does NOT recognize the UPPERCASE filename, finding only the lowercase one.

In the same situation BP answers l 0 u 0 i.e. it recognizes both.

The defect can be traced to the function MatchPart in the FindNext procedure. Correction need to be done only under DJGPP (at compilation time) when LFN=n at execution time. A possible solution is given by the attached diff.

Thanks for the report. I fixed this -- actually a bit more general: I put into the RTS a new constant FileNamesCaseSensitive and a new function FLoCase to convert a character to lower case if FileNamesCaseSensitive is False and leave it unchanged otherwise, and use them in the Dos unit, so that unit doesn't need any ifdefs.

However, I'm not sure about when FileNamesCaseSensitive should be set to False: First of all, I think it should be on all __OS_DOS__ platforms, not only __DJGPP__. Then, what about the LFN stuff? I haven't used such a system, but I've read that it's not really case-sensitive (something like, the case of the files as given on creation is stored, but matching is still insensitive). If that's so, FileNamesCaseSensitive should still be False, and we don't have to check LFN. Can anyone confirm or deny?

Similarly the environment names are always capitalized, so that GetEnv('path') and GetEnv('PATH') give the same result as displyed in the following short program:

program ge; uses dos; var F:SearchRec; begin writeln('LFN=',GetEnv('LFN')); writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); end.

BTW, something unrelated to your request: when searching for an executable, you might prefer to use:

FSearchExecutable ('rhide', GetEnv (PathEnvVar));

This searches for `rhide.com', `rhide.exe' and `rhide.bat' under Dos (so you get more flexibility there), and on other systems for `rhide' without extension (so it works there, too) and only with executable permission (so it's safer than "FSearch ('rhide', ...)" there). PathEnvVar is currently 'PATH' on all systems, but one never knows what will happen... ;-)

BTW, FSearchExecutable and PathEnvVar need the `gpc' unit rather than `dos' (and `FSearch' and `GetEnv' are also present in `gpc' as well as in `dos').

DJGPP in DOS 6 with LFN=n answers:

LFN=n ll uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe

whereas in BP gives always (even in a W95 dos box)

LFN= ll F:\DJGPP\BIN\rhide.exe uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe

This behavior of automatic capitalization of environment variables is so strange that I am not sure it must be reproduced in a unit which aims at portability: I think that nearly everybody would write naturally programs with environment variables uppercase as displayed by the set command.

Actually, I have changed this after 19990118 (only for Dos, of course, not affecting other systems where case matters). This is the corresponding entry from the `Fixed bugs' section of the To-Do list (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html):

19990202: Dos-like systems: convert parameter to GetEnv and CGetEnv to upper case (actually, libc should do so)

A completely different bug is in the crt unit. Readkey returns #10 i.e. linefeed when one hits the return as well as the ^M keys which should be #13. THis is very strange since the demo program testcurs.c which comes with the sources of PDcurses has the correct behavior.

Oh yes, these CR/LF stuff is a bit nasty because if seems to depend on a number of things like terminal modes, which are affected by CheckBreak (perhaps a bug in PDCurses, at least a bit of undocumented behaviour there ;-). I changed CRT a little after 1990118, hope this will also fix the symptom you've experienced:

19990202: DJGPP: CRT: ReadKey returns #10, not #13, for the enter key when CheckBreak is True

Frank