w32-convert-standard-filename  is a different function.

I am at my machine now.  The correct spelling is
w32-short-file-name

w32-short-file-name is a built-in function in `C source code'.

(w32-short-file-name FILENAME)

Return the short file name version (8.3) of the full path of FILENAME.
If FILENAME does not exist, return nil.
All path elements in FILENAME are converted to their short names.



For example,

(w32-short-file-name "c:\Program Files")
"c:/PROGRA~1"

(w32-short-file-name "c:\Program Files (x86)")
"c:/PROGRA~2"

(w32-short-file-name "c:/Program Files (x86)/MiKTeX 2.9/")
"c:/PROGRA~2/MIKTEX~1.9/"




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

> On 4/18/2013 12:24 PM, Rmh wrote:
>
>> try using w32-shortname ( or something similar, i am not at my machine to
>> check the right spelling).
>> that gives the 8.3 name ( which is unfortunately machine dependent)
>>
>> Rich
>>
> w32-convert-standard-filename does strip the leading spaces, but uses
> "!C!" where I would expect "C:".
> convert-standard-filename does the same thing.
> help system didn't turn up a shortname version, but the length of the name
> is not the problem.
>
> I tried using the path starting with !C! to launch Rterm; it didn't work
> ("permission denied").
>
> Also, I'm just curious why the regexp isn't matching as I expect.
>
> Ross
>
>
>> Sent from my iPhone
>>
>> On Apr 18, 2013, at 15:12, Ross Boylan <ross@biostat.ucsf.edu> wrote:
>>
>>  I tried using my macro on an XP machine and it didn't work.  There were
>>> 2 problems, one of which I need help solving.
>>>
>>> On 3/28/2013 1:51 PM, Ross Boylan wrote:
>>>
>>>> (defun installPath-reg-read (regpath)
>>>>   ;read a path in the Windows registry. This probably works for string
>>>>   ;values only. If the path does not exist, it returns nil.
>>>>   ;Adapted from source:
>>>> ;http://stackoverflow.com/**questions/7436530/can-i-read-**
>>>> the-windows-registry-from-**within-elisp-how<http://stackoverflow.com/questions/7436530/can-i-read-the-windows-registry-from-within-elisp-how>
>>>>   (let ((reg.exe (concat (getenv "windir") "\\system32\\reg.exe"))
>>>>         tokens last-token)
>>>>
>>>>     (setq reg-value (shell-command-to-string (concat reg.exe " query "
>>>> regpath " /v InstallPath"))
>>>>           tokens (split-string reg-value nil t)
>>>>           last-token (nth (1- (length tokens)) tokens))
>>>>
>>>>     (and (not (string= last-token "value.")) last-token)))
>>>>
>>> The first problem is that on XP failure to find a value produces a
>>> string ending in "value" without a period.  I added a test for that.
>>>
>>> The second problem, which is not XP-specific, is that last-token is not
>>> the right value if there are spaces in the path.
>>> I tried extracting everything after REG_SZ, but I keep getting the
>>> whitespace before the string I'm interested in.  Sample attempt
>>> (string-match "^.*REG_SZ *\\([^ ].*\\) *" tlong)
>>> (match-string 1 tlong)
>>> where tlong is my temporary variable corresponding to reg-value above.
>>>  I've also tried [:space:].
>>> I either fail to match or get a match that includes a bunch of leading
>>> white-space, perhaps a tab.
>>>
>>> Any suggestions how to fix this?  Maybe if I looked at the character
>>> codes in the string it would help, but the characters visually are
>>> whitespace, and so I don't know that the problem is.  My understanding is
>>> that  a space in a regular expression will match at least a space or a tab
>>> (emacs 24.3.1).
>>>
>>> tlong is multi-line, if that matters.  The fact that it's the result of
>>> shell-command-to-string may be more important in making it behave oddly.
>>>
>>> Thanks.
>>> Ross
>>>
>>> P.S. The code with tlong is typed manually and so might have a
>>> transcription error, though I don't see one.
>>>
>>> ______________________________**________________
>>> ESS-help@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/**listinfo/ess-help<https://stat.ethz.ch/mailman/listinfo/ess-help>
>>>
>>
>

	[[alternative HTML version deleted]]

