Re: substitute-in-file-name and "$"

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Michael Albinus wrote:

   `PC-do-completion' must do it, because the result is shown in the
   minibuffer.

   Or a file name like this: "$NEXT_HOP:/share$$", where $NEXT_HOP has
   the value "/smb:next.hop.com". At least case (2) would be needed,
   because Tramp file name handler could be activated only after applying
   substitute-in-file-name to that file name.

You can always double up all $'s if your function only has access to
an already substituted filename.  (Putting a /: at the beginning would
be easier, but that could probably cause remote filenames to be
considered local.)  All functions have to make clear in their
documentation string what they are going to do to file names (if
anything) and in which form they return them, if non-standard.  If
they do not, that is a bug.  This is not madness.  It is completely
obvious.  Functions need to say what they do.  People who use
functions need to know exactly what they do, not more or less what
they do.  It is usually easier to be able to find this out by reading
documentation strings than by carefully reading through every single
line of code of the function itself and of all indirectly called
functions.

   A simpler approach would be: expand environment variables if
   possible. Don't worry if you cannot expand.

   The masquing with "$$" wouldn't be necessary this case. But I don't
   know whether there are other drawbacks with this approach.

What if somebody has an environment variable FOO expanding to bar and
another file named $FOO?  Several operating systems, including GNU and
Unix, allow people to essentially use any file names of their
choosing, no matter how perverse.  Programs have to be able to handle
that, even though that might make life complicated.

Sincerely,

Luc.