Open dertuxmalwieder opened 3 months ago
The step seems to be a custom step, i.e., not a built-in step supported by Topgrade, right?
Topgrade can't properly resolve ~ on some shells,
If this is a custom step, then Topgrade does not resolve the ~
sign itself, it passes it to the shell.
/Users/tux0r/.local/bin/rc
Looks like you are using a shell called rc
, does this issue exist if you change the shell to something else, e.g., the default zsh?
The step seems to be a custom step, i.e., not a built-in step supported by Topgrade, right?
Depends. All I did was uncomment a line in the supported ;-) default configuration: https://github.com/topgrade-rs/topgrade/blob/main/config.example.toml#L80
Yes, the rc
shell does not "auto-expand" the ~
, so my suggestion to use $HOME
instead could also avoid further issues, I guess?
Yes, the rc shell does not "auto-expand" the
~
Interesting, this is the first shell that I know that doesn't expand the ~
sign 🤔
Depends. All I did was uncomment a line in the supported ;-) default configuration:
Yeah, that is a custom pre-command, you can write any shell script there that can be interrupted by your shell.
So my suggestion to use $HOME instead could also avoid further issues, I guess?
The current script would work for most shells, you can edit the command in your configuration file to expand the ~
yourself. ;)
Erroneous Behavior
I switched from Elpaca to the built-in Emacs package manager last month, trying to reduce the number of possible points of failure (and the complexity of my configuration). Today I thought that I might want to re-enable the Emacs step in Topgrade as well. (I had it disabled while I didn't use
package.el
.)However, it won't work too well.
It looks like Topgrade can't properly resolve
~
on some shells, because I am absolutely sure that/Users/tux0r/.emacs.d/elpa
exists (and is not a hard link).Expected Behavior
Well, it shouldn't break.
Steps to reproduce
Just use Topgrade's built-in Emacs updater.
Problem persists without calling from topgrade
Maybe it would make sense to use
$HOME
instead?Did you run topgrade through
Remote Execution
If yes, does the issue still occur when you run topgrade directlly in your remote host
Additional Details
Operation System/Version macOS Sonoma
Installation via Homebrew
Topgrade version (
topgrade -V
) Topgrade 15.0.0Verbose Output (
topgrade -v
)