On 13294 March 1977, Romain Francoise wrote: > Hi, > > "Joerg Jaspert" <jo...@ganneff.de> writes: >> next oddity i found is list-commands, which only works when a tmux >> session exists. Yet I see no reason for this limitation, as, as far as >> I see, the output doesn't depend on a running session (unlike >> list-sessions for example). > First of all, the output *does* depend on the running server. If your > client and server are not in sync (because you upgraded the client but > not the server), only the server can know the list of supported > commands.
You mean having a server run, then upgrade, and then next run? Hrm. > More generally, everything in tmux is implemented in the server, the > client is really dumb and just sends to the server any arguments you > give it, along with some file descriptors. Command parsing and dispatch > is done in the server, and list-commands is not special in that regard. > So you really do need a running server for list-commands to work. I wonder. Isn't client and server in the same binary? Couldn't the client run a server when there is none (and then dismantle it after use), for things it needs a server for? Or is that "too much logic" for the dumb client part? Yeah, I implemented something like this myself now, having a tmux session with a random name for a short time, but it looks silly, IMO. For something our overpriced and usually quite bored hardware could be doing. Instead of wasting cpu cycles by ... idling. :) -- bye, Joerg <dannf> asking an engineer at hp for part numbers is like asking Ganneff for the right mixture of fuel for a 747 - i might happen to know (like if i'd just ordered one) or might know someone who knows, but its a crapshoot :) ) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
