GNU bug report logs - #5808
23.1; substitute-in-file-name $NOSUCH vs ${NOSUCH}

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5808 in the body.
You can then email your comments to 5808 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; substitute-in-file-name $NOSUCH vs ${NOSUCH}
Date: Wed, 31 Mar 2010 11:18:39 +1100

Evaluating

    (substitute-in-file-name "$NOSUCHVAR")
    => "$NOSUCHVAR

but

    (substitute-in-file-name "${NOSUCHVAR}")
    => error
    Substituting nonexistent environment variable "NOSUCHVAR"

whereas I thought the two ways of writing a variable would be treated
the same.

I'm not sure if this is a bug or a feature.  I see they were both errors
in Emacs 21, but that 22 up forgives the first.

If a feature then it'd be good if the docstring had a note explaining
the difference.  I'd used then first and then got bitten from the second
throwing an error.

The docstring might also note unpaired braces are an error

    (substitute-in-file-name "${HOME")
    => error

primarily in the interests of knowing what circumstances you might have
to condition-case or ignore-errors.




In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-09-14 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Message #8 received at 5808 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 5808 <at> debbugs.gnu.org
Subject: Re: bug#5808: 23.1; substitute-in-file-name $NOSUCH vs ${NOSUCH}
Date: Tue, 30 Mar 2010 21:29:53 -0400

> Evaluating
>     (substitute-in-file-name "$NOSUCHVAR")
>     => "$NOSUCHVAR
> but
>     (substitute-in-file-name "${NOSUCHVAR}")
>     => error
>     Substituting nonexistent environment variable "NOSUCHVAR"
[...]
> I'm not sure if this is a bug or a feature.  I see they were both errors
> in Emacs 21, but that 22 up forgives the first.

I made the change in Emacs-22 so that most uses of $ in file names can
work without needing the quoting by double-dollars.

It was a fairly easy change which should cover most cases.  Admittedly,
the resulting inconsistency is not great, so I guess that the
discrepancy is a misfeature/bug, but it's not very high up the list of
things to fix.  Patches welcome,


        Stefan

Message #13 received at 5808 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5808 <at> debbugs.gnu.org
Subject: Re: bug#5808: 23.1; substitute-in-file-name $NOSUCH vs ${NOSUCH}
Date: Sat, 03 Apr 2010 11:02:20 +1100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> I made the change in Emacs-22 so that most uses of $ in file names can
> work without needing the quoting by double-dollars.

Sounds likely.

> Admittedly,
> the resulting inconsistency is not great, so I guess that the
> discrepancy is a misfeature/bug,

Unless it's thought of as ${FOO} is certainly an expansion, whereas $FOO
is instead maybe an expansion and maybe a literal $, such as on VMS, is
it?

If the docstring described the way it worked that'd be enough.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.