Re: LFN Utilities for Win32

["Robert Holmgren" holmgren@xxxxxxxx]

Important fixes to LFN -- see URL below, and one new file to install
(CHOICE.COM).

Answers to a couple of questions posed publicly and privately, which might be
useful:

One person asked:

> Next, focusing on the existence of file "address book fragment
> 1.text", I issued DIRLFN *frag*. Should have listed (at a
> minimum) that file, no?

Actually, no. It's "DIRSFN *frag*"

DIRLFN accepts an 8.3 dirmask (unless you are looking at an existing Xy4
directory and issue DIRLFN without an argument). In other words, it returns
the LFNs for an SFN dirmask.

DIRSFN does the opposite: it processes *any* (LFN or 8.3) dirmask (like
"*frag*") and returns the SFNs that XyWrite can actually use. Suppose you have
an Address Book, a Restaurant Book, a Client Book etc -- you might argue
"DIRSFN *book*" (case insensitive) to get the SFNs of these various books.
Obviously, this would be impossible to do natively in XyWrite, since the
commonality that is the focus of your dirspec, the substring "book", would not
be reflected in any way in the truncated 8.3 short names of these several files.

Now, you might put the case that the framenames I've chosen are the reverse of
common sense. It's all in how you think about them (they are transformative --
SFN==>LFN and LFN==>SFN -- so I guess the question is whether the framenames
should denote the input or the result). I'm very amenable to changing them if
it's confusing. But I think they ought to be similar (to indicate their
complementary character), and also *short* (CMline space being at a premium).

Both of these commands yield, in the end, usable XyWrite directories that look
very similar.

Re: high-order (e.g. accented) characters (>127) in filenames. It's a tricky
issue, and depends heavily on the file system (FAT[32] or NTFS) and the OpSys.
NTFS, for example, seems to always work. FAT is completely flaky -- sometimes
you can display a XyWrite directory of these files, but then you can't CAll
them. Sometimes XyWrite considers the characters to be illegal, and other
times the command processor won't recognize them. Without going into this at
length (this is basically a non-issue in North America, and I think very rare
elsewhere), the bottom line is that I've built a strong procedure that enables
any file to be dir-listed (LFNed) *if* the file passes XyWrite's EXIST test.
EXIST really is the final arbiter of whether a file can be CAlled or not
(regardless of whether it can be DIRectoried). If EXIST says a file can't be
CAlled, then LFN puts a "Not found" prompt. This does not mean that it
absolutely 100% doesn't exist -- but as far as XyWrite is concerned, and given
that the tools I'm using operate within XyWrite, the file is, well, not found.

When the *first* file processed in a DIRLFN directory listing is "Not found",
the routine goes into an endless loop. Fixed.

In four cases -- COPY, COPY/MV, COPY/NV, and REN -- I've substituted
built-on-the-fly CMD files for direct BX ... Q2 CMline commands. Several
reasons:

- the puny 100 char limit on arguments that XyWrite can pass to DOS
- flakiness of KMD.EXE's "COPY /-Y" switch (force overwrite verification)
- KMD overwrite verification requires a Y/N, and then  (too many keystrokes)

So I've added a tiny file, CHOICE.COM, to the LFN.ZIP. CHOICE.COM *must* be
installed in the same top-level PATH directory as KMD.EXE. Operation is the
same (one less key to push -- just Y or N, overwrite or skip). The
verification prompt "bleeds through" from DOS at current cursor position. You
have 10 seconds to make a Y\N choice, otherwise it defaults to No.

Added switches to the SFN command: /PV [PutValue=print d:\path\filename to
screen], /NV [NoVerify=no prompt displayed], and /FI [FIlename only, no path
reported]

Getting down to the short hairs here... Pretty solid, I think.

A new build of LFN is posted at:

 http://users.datarealm.com/xywwweb/LFN.ZIP

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------