GNU bug report logs - #76955
30.1; php-ts-mode-php-executable default path may not match remote path

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Morgan Willcock <morgan <at> ice9.digital>
Cc: v.pupillo <at> gmail.com, 76955 <at> debbugs.gnu.org
Subject: bug#76955: 30.1; php-ts-mode-php-executable default path may not match remote path
Date: Sat, 15 Mar 2025 18:09:10 +0200

> From: Morgan Willcock <morgan <at> ice9.digital>
> Cc: v.pupillo <at> gmail.com,  76955 <at> debbugs.gnu.org
> Date: Sat, 15 Mar 2025 15:03:57 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >From my perspective as a user of mode, just setting the value to "php"
> >> introduces no additional complexity, works in more places by default
> >> than the current value, and doesn't deviate from how other modes (and
> >> associated executable paths) are managed.
> >
> > My suggestion will still work in your case, no?
> 
> It would work in my particular case, but it also means that someone who
> installed their own executable at "~/bin/php" on both the local and
> remote systems, and then customised the value to "~/bin/php", would now
> have a new class of problem on the remote system.

Customizing the variable to "~/bin/php" will only work if it is
correct for _all_ the remote systems, as you yourself pointed out.
Which is unlikely to happen.

And adding "~/bin" to PATH to fix this particular case is a
no-brainer.

So I still insist that my proposal is better than just changing the
default value to "php".

> I don't think it is feasible to begin a precedent that any code which
> attempts to run an executable should now explicitly check whether the
> system is remote and assume that it knows better than the user's
> configuration.  I don't know the codebase well enough to declare that
> there are no other instances of this happening, but I can show a similar
> problem:
> 
>   (setq find-program "c:/ezwinports/bin/find.exe")

If you do that, you are using those ports contrary to my suggestions,
which is to have a Posix-style tree with bin/, share/,
etc. subdirectories, add the bin/ subdirectory to PATH, and unzip all
the ports into the same tree.  That way, everything works seamlessly
and without problems.

> Having set this value, I have now broken the ability to use find on any
> remote system where this path doesn't exist.

The difference between Find and "php" is that the former is used by
several Emacs packages, and is a general-purpose program that should
be easily found on any system.  By contrast, "php" is used only by
this mode, and so the possibility for it to be not on PATH is higher.

But if it _is_ on PATH, then customizing the value to just "php" will
get users what they will have if we change the default to just "php".

> That said, I do not claim to be TRAMP expert, I just use it.  A TRAMP
> maintainer is probably better positioned to clarify the preferable way
> to configure paths to executables so they work locally and remotely.

Then let's stop arguing and install the change.

Previous Next

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