[ANNOUNCEMENT] tmux 3.2-0

[ANNOUNCEMENT] tmux 3.2-0

[Michael Wild via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* tmux-3.2-0

tmux enables a number of terminals (or windows) to be accessed and
controlled from a single terminal like screen. tmux runs as a server-client
system. A server is created automatically when necessary and holds a number of
sessions, each of which may have a number of windows linked to it. Any number
of clients may connect to a session, or the server may be controlled by issuing
commands with tmux. Communication takes place through a socket, by default
placed in /tmp. Moreover tmux provides a consistent and well-documented command
interface, with the same syntax whether used interactively, as a key binding,
or from the shell. It offers a choice of vim or Emacs key layouts.

Re: [ANNOUNCEMENT] tmux 3.2-0

[Achim Gratz]

Michael Wild via Cygwin-announce via Cygwin writes:
> The following packages have been uploaded to the Cygwin distribution:
>
> * tmux-3.2-0

[nit]
General releases should be numbered starting with 1.


The mosh test suite breaks with this release (the same build tests OK
again with tmux-3.1b), apparently because it is using control mode to
test that zmux actually works and something seems to have changed there
(the command line is 'tmux -C new-session true').  The symptom is that
the whole test just hangs with absolutely no activity until I kill tmux,
at which point the expected output from the control mode session does
seem to appear (except with a return code of 99).

Is the control mode working as intended and if yes, is there a way to
get the old behaviour back that did send the output block to stdout and
then terminated?


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[Bug] tmux 3.2-0

[Achim Gratz]

Achim Gratz writes:
> Michael Wild via Cygwin-announce via Cygwin writes:
>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * tmux-3.2-0
>
> [nit]
> General releases should be numbered starting with 1.
>
> Is the control mode working as intended and if yes, is there a way to
> get the old behaviour back that did send the output block to stdout and
> then terminated?

Control mode isn't working correctly in Cygwin (compared to the same
version of tmux in Linux).  The expected output never makes it to the
control mode client.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Bug] tmux 3.2-0

[Michael Wild]

On Tue, May 25, 2021 at 11:02 PM Achim Gratz wrote:
>
> Achim Gratz writes:
> > Michael Wild via Cygwin-announce via Cygwin writes:
> >> The following packages have been uploaded to the Cygwin distribution:
> >>
> >> * tmux-3.2-0
> >
> > [nit]
> > General releases should be numbered starting with 1.
> >
> > Is the control mode working as intended and if yes, is there a way to
> > get the old behaviour back that did send the output block to stdout and
> > then terminated?
>
> Control mode isn't working correctly in Cygwin (compared to the same
> version of tmux in Linux).  The expected output never makes it to the
> control mode client.

Hi Achim

Sorry for the mistake with the release number. Should that be a sanity
check in calm?

As for the problem with the control mode: Is there anything I can do?
Like forwarding the problem to upstream? Or do you consider it to be
"unfixable" until Cygwin implements the control mode properly?

Michael

Re: [Bug] tmux 3.2-0

[ASSI]

Michael Wild via Cygwin writes:
> Sorry for the mistake with the release number. Should that be a sanity
> check in calm?

I personally don't think so, if you want to do a test / pre-release then
starting with a "0" seems netural to me.

> As for the problem with the control mode: Is there anything I can do?

Since it's clearly a regression (on cygwin), it would be a start to
check if any new warnings have popped up during compilation.

> Like forwarding the problem to upstream? Or do you consider it to be
> "unfixable" until Cygwin implements the control mode properly?

I don't know, I haven't looked beyond the fact that

tmux -C new

doesn't give you any of the expected output and indefinitely hangs
(although it seems to process at least some commands that you enter).  I
still hope it might just be a misguided #ifdef targeting Cygwin or some
simarly silly mistake.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Bug] tmux 3.2-0

[Michael Wild]

On Wed, May 26, 2021 at 12:08 PM ASSI wrote:
>
> Michael Wild via Cygwin writes:
> > Sorry for the mistake with the release number. Should that be a sanity
> > check in calm?
>
> I personally don't think so, if you want to do a test / pre-release then
> starting with a "0" seems netural to me.
>
> > As for the problem with the control mode: Is there anything I can do?
>
> Since it's clearly a regression (on cygwin), it would be a start to
> check if any new warnings have popped up during compilation.
>
> > Like forwarding the problem to upstream? Or do you consider it to be
> > "unfixable" until Cygwin implements the control mode properly?
>
> I don't know, I haven't looked beyond the fact that
>
> tmux -C new
>
> doesn't give you any of the expected output and indefinitely hangs
> (although it seems to process at least some commands that you enter).  I
> still hope it might just be a misguided #ifdef targeting Cygwin or some
> simarly silly mistake.
>
>
> Regards,
> Achim.

I just tried the following:

Terminal 1:
$ tmux new -s mysession

Terminal 2:
$ tmux -C attach -t mysession
split-window
split-window -h

And as expected, in Terminal 1 the window got split first vertically,
then horizontally. However, in version 3.1b Terminal 2 was echoing the
commands from Terminal 1. This doesn't happen with version 3.2
anymore. I verified by building 3.2 in WSL 2 (Ubuntu 20.04) and there
the echoing does work.

Just out of curiosity: is this a critical feature for you? E.g. are
you automating tmux with it? Because as far as I understand control
mode is intended for integration with terminal emulators. And so far,
iTerm2 on Mac is the only one implementing the protocol.

Regards

Michael

Re: [Bug] tmux 3.2-0

[Achim Gratz]

Michael Wild via Cygwin writes:
> Just out of curiosity: is this a critical feature for you? E.g. are
> you automating tmux with it? Because as far as I understand control
> mode is intended for integration with terminal emulators. And so far,
> iTerm2 on Mac is the only one implementing the protocol.

As I said in the original posting, the test suite for mosh makes use of
control mode.  Besides the terminal integration (that is non-existing on
Cygwin AFAIK) this sort of controlling terminals from scripts/automation
is probably uncommon.  GNU parallel might be using control mode too,
although I've not tried that mode and it has no official Cygwin package
either (but I use it on Cygwin).  OTOH, it is surprising that control
mode suddenly stopped working in Cygwin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Bug] tmux 3.2-0

[Michael Wild]

On Mon, May 31, 2021 at 8:30 PM Achim Gratz wrote:
>
> Michael Wild via Cygwin writes:
> > Just out of curiosity: is this a critical feature for you? E.g. are
> > you automating tmux with it? Because as far as I understand control
> > mode is intended for integration with terminal emulators. And so far,
> > iTerm2 on Mac is the only one implementing the protocol.
>
> As I said in the original posting, the test suite for mosh makes use of
> control mode.  Besides the terminal integration (that is non-existing on
> Cygwin AFAIK) this sort of controlling terminals from scripts/automation
> is probably uncommon.  GNU parallel might be using control mode too,
> although I've not tried that mode and it has no official Cygwin package
> either (but I use it on Cygwin).  OTOH, it is surprising that control
> mode suddenly stopped working in Cygwin.

I opened an issue with upstream: https://github.com/tmux/tmux/issues/2725.

It appears that the problem is not a simple #ifdef missing. Tmux is
now passing the file handle for stdout from the client to the server
processes, something that Cygwin doesn't support (see
https://sourceware.org/legacy-ml/cygwin/2004-01/msg00060.html). The
upstream author mentioned a potential workaround. Maybe there's
someone with the necessary skills here on the mailing list who has the
time to lend him a hand?

Regards

Michael

Re: [Bug] tmux 3.2-0

[Michael Wild]

> > [...]
> > As I said in the original posting, the test suite for mosh makes use of
> > control mode.
> > [...]

I just uploaded a patched test version 3.2-1 (yeah, I know, I'm off by
one with the release number...). Can you give it a go and see whether
the mosh test suite runs through with it?

Cheers

Michael

Re: [Bug] tmux 3.2-0

[ASSI]

Michael Wild via Cygwin writes:
> I just uploaded a patched test version 3.2-1 (yeah, I know, I'm off by
> one with the release number...). Can you give it a go and see whether
> the mosh test suite runs through with it?

I'll have a look, but it'll probably at the weekend.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [Bug] tmux 3.2-0

[ASSI]

Michael Wild via Cygwin writes:
> I just uploaded a patched test version 3.2-1 (yeah, I know, I'm off by
> one with the release number...). Can you give it a go and see whether
> the mosh test suite runs through with it?

No it doesn't and I don't even understand why anybody thinks that would
fix the issue.  The output is supposed to go to stdout (that's the sole
purpose of control mode) and it's the fd for the TTY that gets
duplicated there apparently (why that only exists for Cygwin if I'm
reading it correctly is another mystery).  So indeed the output now appears on the
terminal, but that's not where it should go when stdout gets redirected
elsewhere.

It _might_ be possible for this particular case that one could open
/proc/${clientpid}/fd/1 and have it do the right thing.  If so, then the
call just above that clobbers stdin with the ttyname would probably be
better off as /proc/${clientpid}/fd/0.

Otherwise with the code changes as implemented you'd need to wait for
the AF_UNIX branch by Ken Brown to finally land before tmux works as
intended again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Bug] tmux 3.2-0

[Achim Gratz]

ASSI writes:
> It _might_ be possible for this particular case that one could open
> /proc/${clientpid}/fd/1 and have it do the right thing.  If so, then the
> call just above that clobbers stdin with the ttyname would probably be
> better off as /proc/${clientpid}/fd/0.

To paraphrase Douglas N. Adams:  If you try that, it will do something that's almost,
but not quite, entirely unlike what you wanted it to do.

--8<---------------cut here---------------start------------->8---
--- origsrc/tmux-3.2/configure.ac       2021-04-13 09:37:43.000000000 +0200
+++ src/tmux-3.2/configure.ac   2021-06-05 11:31:12.985505400 +0200
@@ -1,6 +1,6 @@
 # configure.ac
 
-AC_INIT([tmux], 3.2)
+AC_INIT([tmux], 3.2p1)
 AC_PREREQ([2.60])
 
 AC_CONFIG_AUX_DIR(etc)
--- origsrc/tmux-3.2/server-client.c    2021-06-05 09:29:04.102404100 +0200
+++ src/tmux-3.2/server-client.c        2021-06-05 11:36:50.162975600 +0200
@@ -2269,7 +2269,19 @@ server_client_dispatch_identify(struct c
        log_debug("client %p name is %s", c, c->name);
 
 #ifdef __CYGWIN__
        c->fd = open(c->ttyname, O_RDWR|O_NOCTTY);
+       /* nope
+       c->out_fd = dup(c->fd);
+        */
+       if (0 < c->pid) {
+         /* UNIX domain sockets can't be used to transfer open fd on Cygwin yet */
+         char *fdnstr = NULL;
+         int fdnsz = asprintf(&fdnstr, "/proc/%u/fd/1", c->pid);
+         if (0 < fdnsz) {
+           c->out_fd = open(fdnstr, O_RDWR|O_NOCTTY);
+           free(fdnstr);
+         }
+       }
 #endif
 
        if (c->flags & CLIENT_CONTROL)
--8<---------------cut here---------------end--------------->8---

It actually runs half the tests that way, but the other half hangs up
for unknown reasons.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra