I just did some experiments too.
w32-short-file-name
needs a valid file name.  It is doing the same as the msdos  'dir /x
"c:\Program Files"'

I haven't used previously.  It seems to be designed to convert valid linux
names into valid msdos names.  it isn't doing anything useful for your
examples (if I understand your examples).

Here is a non-existent file with an embedded blank, one version also has a
leading blank.

(w32-convert-standard-filename "c:/abcd Files (x86)/ghij 2.9/")
"c:/abcd Files (x86)/ghij 2.9/"
(w32-convert-standard-filename " c:/abcd Files (x86)/ghij 2.9/")
" c!/abcd Files (x86)/ghij 2.9/"


Can you isolate the actual strings you are trying to interpret and send
them?


On Thu, Apr 18, 2013 at 4:57 PM, Ross Boylan <ross@biostat.ucsf.edu> wrote:

>  On 4/18/2013 1:37 PM, Richard M. Heiberger wrote:
>
> w32-convert-standard-filename  is a different function.
>
>  I am at my machine now.  The correct spelling is
> w32-short-file-name
>
> That returns nil in this case.  I'm guessing from the behavior I see that
> it only returns values for paths of actual files; probably the leading
> whitespace screws it up.
> Ross
>
>

	[[alternative HTML version deleted]]

