bug#40949: 26.3; substitute-env-in-file-name: Undefined variables not substituted

bug#40949: 26.3; substitute-env-in-file-name: Undefined variables not substituted

[Marcus Harnisch]

With commit ee041f2d07b6ed485dc34c115588f973f046c9d4 the function
`substitute-env-in-file-name' was introduced.

The function substitutes environment variable references in filenames
with the help of `substitute-env-vars'. On systems that are neither
windows-nt nor ms-dos, the optional argument to that function is set to
t with the consequence that references to undefined variables are not
substituted. This is unexpected, IMHO.
Expected behaviour would match that of shell expansion, which
substitutes undefined variables with the empty string.

Cheers,
Marcus

bug#40949: 26.3; substitute-env-in-file-name: Undefined variables not substituted

[Eli Zaretskii]

> From: Marcus Harnisch <marcus.harnisch@gmx.net>
> Date: Tue, 28 Apr 2020 22:38:14 +0200
> 
> With commit ee041f2d07b6ed485dc34c115588f973f046c9d4 the function
> `substitute-env-in-file-name' was introduced.
> 
> The function substitutes environment variable references in filenames
> with the help of `substitute-env-vars'. On systems that are neither
> windows-nt nor ms-dos, the optional argument to that function is set to
> t with the consequence that references to undefined variables are not
> substituted. This is unexpected, IMHO.
> Expected behaviour would match that of shell expansion, which
> substitutes undefined variables with the empty string.

Your report seems to imply that the behavior on MS-Windows is
different, but it isn't: if the variable is undefined, we leave it
unaltered on those systems as well.

Whether Emacs should follow what the shell does is a separate issue.
In this case, since we use this function in substitute-in-file-name,
what it does should serve what substitute-in-file-name was always
doing: it left the $foo constructs unaltered.

bug#40949: 26.3; substitute-env-in-file-name: Undefined variables not substituted

[Marcus Harnisch]

On 29/04/2020 13.27, Eli Zaretskii wrote:
> Your report seems to imply that the behavior on MS-Windows is
> different, but it isn't: if the variable is undefined, we leave it
> unaltered on those systems as well.
The definition is special-cased for MS-Windows (passes result of getenv 
as opposed to a hardcoded t as optional argument to substitute-env-vars) 
and I am not able to check the relevant behaviour on that platform. 
That's why I pointed it out.
> Whether Emacs should follow what the shell does is a separate issue.
> In this case, since we use this function in substitute-in-file-name,
> what it does should serve what substitute-in-file-name was always
> doing: it left the $foo constructs unaltered.
It is probably moot to argue against long-standing practice, but the 
behaviour could perhaps benefit from a note in docstrings of functions 
that rely on `s-e-i-f-n'. Having used Emacsen and POSIX systems for 
about the same number of decades, I found this difference (Emacs vs 
shell) rather surprising.

Thanks,
Marcus

bug#40949: 26.3; substitute-env-in-file-name: Undefined variables not substituted

[Lars Ingebrigtsen]

Marcus Harnisch <marcus.harnisch@gmx.net> writes:

>> Whether Emacs should follow what the shell does is a separate issue.
>> In this case, since we use this function in substitute-in-file-name,
>> what it does should serve what substitute-in-file-name was always
>> doing: it left the $foo constructs unaltered.
> It is probably moot to argue against long-standing practice, but the
> behaviour could perhaps benefit from a note in docstrings of functions
> that rely on `s-e-i-f-n'.

Makes sense -- it is somewhat surprising behaviour, so I've now done
this in Emacs 28 for substitute-in-file-name.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no