bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Environmental variable expansion - problems for Shares.


From: Steve Kemp
Subject: Environmental variable expansion - problems for Shares.
Date: Mon, 8 Oct 2001 15:32:29 +0100 (BST)

In GNU Emacs 20.7.1 (i386-*-nt5.0.2195)
 of Fri Sep 29 2000 on MP3-Jukebox
configured using `configure NT'


  Under MS Windows operating systems the TAB-completion of
 filenames can fail, when dealing with "hidden" network shares.

  Under these operating systems shared directories are "hidden"
 by suffixing their names with a "$" symbol.

  When attempting to use tab completion on these directory names
 Emacs attempts to expand an environmental variable, and invariably
 fails.

  For example a sample run might look like this:

  Emacs.exe -q -no-init-file
  Ctrl-x Ctrl-f                   (find-file).
  \\machine\C$\Win[TAB]           (attempt to tab complete, to Winnt).

  -> Error 'Substituting nonexistent environment variable ""'

  The backtrace looks like this:

  Signaling: (error "Substituting nonexistent environment variable \"\"")
  read-file-name-internal("\\\\machine\\C$\\win" "~/" nil)
  minibuffer-complete()
  call-interactively(minibuffer-complete)
  call-interactively(find-file)
  recursive-edit()

   After a cursory look at the code it seems that the "$\" string
  is being treated as an environmental variable to expand.

   The cause of this appears to be the code code in fileio.c, in the
  function `substitute-in-file-name'

        /* Get variable value */
        o = (unsigned char *) egetenv (target);
        if (!o)
          goto badvar;

   One potential fix is to change this to something like this:

        /* Get variable value */
        o = (unsigned char *) egetenv (target);
        if (!o)
        {
                o = strdup( target );
        }

  This would deal with this case, but would be a poor general
 solution - as it would probably suprize the user, (and rightly
 so).

   I'm not sure what the proper solution is - but I'd love a fix
 for this behaviour..

  Perhaps the best thing to do would be to have the option to disable
 the variable expansion - then we could set this to automatically
 "disabled" under Windows, unless the user wished to enable it.

   enable-file-env-expansion, or similar?

Steve
---
# GNU Software for Windows.
http://www.gnusoftware.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]