Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
> but this time I can confirm the source of issue. This time I ran
> rpctrace directly on vim, and used two printfs to locate the isatty().
>
> ```
> printf ("Start isatty!\n");
> if (mch_isatty(in))
> channel->ch_to_be_closed |= (1U << PART_IN);
> printf ("Finish isatty!\n");
> ```
>
> rpctrace output:
> ```
> ...
> 30<--44(pid920)->io_write_request ("Start isatty!\n" -1) = 0 14
> 56<--24(pid920)->term_getctty () = 0x4000002d (Operation not supported)
> 30<--44(pid920)->io_write_request ("Finish isatty!\n" -1) = 0 15
> ...
> ```
>
> The error seems to be from [2].
Indeed, if it was plugged to another translator you'd get a mig bad id
error.
My guess is that it's cred->pi.class != tty_class that fails, indeed:
int ret = openpty(&master, &slave, s, &term, &win);
printf("%d\n", isatty(master));
printf("%d\n", isatty(slave));
says 0 for master on the Hurd while it says 1 on Linux
The pi.class != tty_class condition was previously because of a lookup,
but nowadays with the protected payloads we didn't need a lookup any
more and it was replaced with a check that we find cred in the proper
place. I'd say we should also accept the class being pty_class, it
does not seem it would harm: in the uses of term_getctty that I can see,
it matches the obtained cttyid with the one of the process, or it's an
explicit request.
> [0]: https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00009.html
> [1]: https://github.com/vim/vim/blob/master/src/channel.c#L1394
> [2]: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/term/users.c#n362
Samuel
