Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make Server.has_session() use returncode #68
has_session() would erroneously return true if tmux returned an unexpected
Instead of adding yet another string to the list to check against, use the
This is untested. While it passed selftest, so did the unpatched version.
referenced this pull request
Aug 17, 2017
@@ Coverage Diff @@ ## master #68 +/- ## ========================================== + Coverage 79.97% 80.14% +0.16% ========================================== Files 8 8 Lines 844 836 -8 ========================================== - Hits 675 670 -5 + Misses 169 166 -3
That simplification looks nice.
To play devil's advocate / pythonics:
What about keep the string comparisons and raising exceptions? e.g. https://libtmux.git-pull.com/en/latest/api.html#exceptions and https://github.com/tony/libtmux/blob/189114cde7e125a482ab984749637fa44d66b284/libtmux/common.py#L523
Older versions of tmux could still subclass a new command base exception like
That way the front-end user could
I need more time on this, because I need to research and assure consistent behavior across older tmux versions.
Does #67 still happen? Does it happen with all tmux versions, or only certain ones?
In #67 (comment) it says:
Can you try again? Have you ruled out it being a partial/fnmatch of the session name?
#67 was caused by the relatively rare situation of a tmux session remaining alive with no sessions, likely due to still having an attached client (somehow) and thus causing an unexpected error message when calling
This PR would fix that issue, and also provide resistance against future changes to
@Shados thank you for the extra info!
@jlargentaye Thanks for the patch!
Looks good so far: https://travis-ci.org/tmux-python/libtmux/builds/352060852
If things go well, we can have this shipped out to 0.8.0, hopefully today.