different session configs with the same path only execute for the first one
Closed this issue · 14 comments
What happened?
When I config some sessions with the same path directory:
[[session]]
name = "update nvim"
path = "/tmp"
startup_command = "brew upgrade neovim --fetch-HEAD && exit"
[[session]]
name = "update all"
path = "/tmp"
startup_command = "brew update && brew upgrade && exit"I expected update nvim and update all to run their own session but only update nvim was executed regardless of session!
Version
1.1.0
Relevant log output
No response
Reviewed
- Reviewed existing issues and made sure this bug has not already been submitted.
- I have read the documentation and understand how sesh works before submitting this bug
correct me if I'm wrong, but I think we should return the found session config command here and pass it to connect function.
https://github.com/joshmedeski/sesh/blob/fe6e6a65d8cb9dbc2f0ab5abdbe15351c5504d96/session/determine.go#L16C4-L20C5
I am actively reworking the connect logic to handle this situation, thanks for flagging this. The first version of sesh was very much dependent on determining the path first, so this new config pattern breaks that pattern.
I'll be sure to mark this issue closed when I complete the work.
I think I have just realised my setup is suffering from this issue too. My sesh.toml has two sessions configured to switch between qlt and tst cloud environments for which Infra-as-Code is maintained in the common Git repository:
[[session]]
name = "qlt"
path = "~/azure-hosting"
startup_script = "~/.config/sesh/scripts/azure-hosting-qlt.sh"
[[session]]
name = "tst"
path = "~/azure-hosting"
startup_script = "~/.config/sesh/scripts/azure-hosting-tst.sh"The sesh connect tst does not load tst environment session, but seems to load the first one in the config, that is sesh connect qlt.
This should be fixed in sesh v2, There's a beta release if you want to test it. The full release is coming in a couple of weeks!
I'm happy to confirm the issue I described in #97 (comment) has now been fixed - I just had to s/startup_script/startup_command/. Thank you @joshmedeski for v2.0!
The #124 can be closed too now, I think.
The startup command will only match by name (not path) so the issue is fixed with the v2 launch!
@joshmedeski Late August I confirmed the fix #97 (comment) works for me. I've just upgraded to latest sesh version dev i.e. I've run go install github.com/joshmedeski/sesh@latest and I'm now observing the problem from this issue back.
This is sesh.toml I've been using for a while now:
[[session]]
name = "azure-hosting-prd"
path = "~/azure-hosting"
startup_command = "~/.config/sesh/scripts/azure-hosting-prd.sh"
[[session]]
name = "azure-hosting-qlt"
path = "~/azure-hosting"
startup_command = "~/.config/sesh/scripts/azure-hosting-qlt.sh"
[[session]]
name = "azure-hosting-tst"
path = "~/azure-hosting"
startup_command = "~/.config/sesh/scripts/azure-hosting-tst.sh"and it is no longer allows to switch to azure-hosting-tst, even if I run sesh connect azure-hosting-tst it always loads and connects azure-hosting-prd. I tested it with killing tmux server completely between trying the sesh connect ... commands.
Interestingly, if I downgrade from sesh version dev to sesh version 2.4.0 then everything works for me again.
IMHO, this issue needs to be re-opened.
Thanks for the update, I can do some debugging and see if I can recreate the issue.
Right now, dev doesn't introduce any new logic from 2.4.0, so I'm wondering why you're getting different results.
To clarify, session config matching only happens by name now (not path), so whatever the bug is will be related to something else.
I can do some debugging and see if I can recreate the issue. (...) dev doesn't introduce any new logic from 2.4.0, so I'm wondering why you're getting different results.
I wish I could help. I can only observe difference in behaviour between the 2.4.0 and current dev.
Perhaps this will help in testing:
-
Here is very simplified version of my sesh configuration and scripts, https://github.com/mloskot/dotfiles/tree/ml/sesh-issue-97/sesh
-
Here is screencast where I replicate my observation of 2.4.0 vs dev:
Screencast.from.2024-10-05.12-44-40.webm
-
Here are commands from the screencast which I run to replicate the observations:
go install github.com/joshmedeski/sesh@latest sesh --version sesh connect azure-hosting-prd # prd is loaded # tmux kill-server to start fresh sesh connect azure-hosting-tst # tst is not loaded, but prd is loaded again curl -o sesh.tar.gz -L https://github.com/joshmedeski/sesh/releases/download/v2.4.0/sesh_Linux_x86_64.tar.gz && \ tar -xf sesh.tar.gz && \ mv sesh $HOME/go/bin sesh --version sesh connect azure-hosting-prd # prd is loaded # tmux kill-server to start fresh sesh connect azure-hosting-tst # tst is loaded
Got it, thanks for the detailed feedback. I can take a closer look at the logic that determines which startup script to run, there is probably a bug in that specific area.
I was unable to reproduce this with the latest version of sesh (in development mode). I couldn't find anything in the code that would be causing this issue, perhaps installing @latest via the go installer is installing a previous version 🤷
For now, can you please stick to using the latest release?
And which OS are you using? Perhaps I can add support for your package manager to make it easier. Thanks again for taking the time to record what's going on.
@joshmedeski Thank you for looking into the issue.
For now, can you please stick to using the latest release?
Yes, of course. I'm happy to stick to the releases.
BTW, I've just tested v2.5.0 and it works well for me.
And which OS are you using?
I'm on Ubuntu 24.04
Perhaps I can add support for your package manager to make it easier.
It's always nice to have .deb -s downloadable for software releases on GitHub, but if it is any burden for you then there may be no point adding it as the tandem of curl and tar do the job well.
Thanks!
Thanks, I'm going to close this for now.
p.s. I worked on deb support before (#68) and ran into some issues, so I'll revisit this again soon.