On Fri, 05 Jul 2013 15:29:18 +0200, Rugxulo <rugx...@gmail.com> wrote:
> Though honestly, the most recent work has been
> done by good ol' Bart Oldemann (another guru), so perhaps he's your
> best bet (and he has SVN write access, unlike me). I'm not really in
> frequent contact with him (me = useless), but he's apparently been
> busy with "real life" (tm). So you can probably email him, but please
> be patient. :-)
Sure, no problem. These issues are fairly low-priority and can be worked
around.
> Agreed, but IIRC it even did something weird (not just printing a 0x7
> BEL ASCII char), maybe direct port write for special chirp.
Yes, it uses the sound and nosound functions. I agree it should just do
putc('\a') for CTTY compatibility. :)
> I wonder if a "visual bell" (a la vi) would be nice here.
I'm not familiar with vi, but filename completion has no reason to beep
anyway. Beeps should be used to get a user's attention when they're doing
something else (if they're at the computer, they're looking at the screen
already).
> 0.82 is the "stable" version (preferred by Eric Auer) and the only one
> on SourceForge, but 0.84 is somewhat preferred by others (at least
> me). 0.82 doesn't support LFNs, that was a later addition (by Blair
> Campbell?, also added DESCRIPT.ION support).
The version I use is "0.84-pre2 XMS_Swap", simply because it's included in
the official FreeDOS 1.0 and 1.1 distributions.
> It may be slightly buggy. Can't remember, something like only on
> default drive or only C:\ or only works if C:\ supports LFNs. I don't
> know, can't remember. All I know is that Eric always said that 0.84
> wasn't heavily vetted for changes.
I have successfully used LFNs on a non-C: drive created by SHSURDRV.
I haven't had any problems with 0.84 except apparently when compiling it
with OpenWatcom.
> BTW, there are some switches that seem to disable LFN in FreeCOM
> output. So I'm not sure of the full ramifications. But yes, I do
> personally "set DIRCMD=/od /lfn"; nevertheless, that won't help for
> other shells (0.82, 4DOS, etc).
Well, FreeCOM is the default, so maybe /LFN should be the default.
> There's still some quirks and bugs. IIRC, you still have to also
> separately say "lfnfor on" and "lfnfor complete on". Also it has some
> problems with files with multiple dots in their names. (BTW, 4DOS
> supports LFNs if you enable it in the .INI file. I don't think /LFN
> works there, maybe not even %DIRCMD%.)
Thanks for informing me about LFNFOR, I wasn't aware of that.
MKDIR seems to work fine with multiple-dot filenames, but COPY does not
(COPY CON one.two.three says "file not found" and "out of memory").
I think LFNFOR and LFNFOR COMPLETE should be off by default because many
programs don't support LFNs. (My own GENPKGLS doesn't, because it uses
OpenWatcom's fopen.)
> BTW, the shell's built-in DIR doesn't have to be exclusively used.
> IIRC, the old 1DIR utility supports LFNs too (among others, e.g. DJGPP
> / GNU ls). And some file managers (Doszip, NDN, Emacs' Dired) also
> support LFNs, so it's not totally dire.
Sure, but as FreeCOM is the default, I think it should make a good
impression. Its feature set is good enough for me. Maybe there should be a
poll asking users which shell/file manager they use?
> It's not fully translated to OpenWatcom yet, IIRC. Bart did some work
> a year or two ago, but he never finished. So it's buggy. The official
> compiler that works is Turbo C (or whatever variant). So, for now, I
> would suggest sticking with that, if you can.
OK, maybe I'll get Turbo C and try that.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
