bug#70519: 30.0.50; Device for Emacs terminal I/O

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Helmut Eller]

I'd like to start Emacs under GDB, but so that Emacs doesn't use the
same terminal as GDB.  It seems that the --terminal command line switch
is there for exactly this use case.

However, it doesn't work.  Emacs parses the command line option and
replaces stdin and stdout with the correct device, but then in dispnew.c
it always calls init_tty with 0 as argument for the device name.  That
simply opens the controlling terminal, i.e. /dev/tty and that is usually
the same device as the one that GDB uses.

What would you think of the change below?

Helmut

diff --git a/src/dispnew.c b/src/dispnew.c
index 0f5063c047f..cc5b883c138 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6710,7 +6710,8 @@ init_display_interactive (void)
     init_foreground_group ();
 
     /* Open a display on the controlling tty. */
-    t = init_tty (0, terminal_type, 1); /* Errors are fatal. */
+    /* Errors are fatal. */
+    t = init_tty (ttyname (STDIN_FILENO), terminal_type, 1);
 
     /* Convert the initial frame to use the new display. */
     if (f->output_method != output_initial)

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Mon, 22 Apr 2024 22:09:18 +0200
> 
> I'd like to start Emacs under GDB, but so that Emacs doesn't use the
> same terminal as GDB.

You should be able to do that with GDB features.  These include:

  . the 'set inferior-tty' command
  . the 'set new-console' command

The first sets the terminal of the debuggee to the named terminal, the
latter causes GDB to create a new terminal each time you "run" a
debuggee, and force the debuggee to use that new terminal.  These
commands should work for you without any changes to the Emacs sources.

Alternatively, you could start GDB from a different terminal and
attach it to an already running Emacs, but this does not allow you to
debug the Emacs startup code.

> It seems that the --terminal command line switch is there for
> exactly this use case.
> 
> However, it doesn't work.  Emacs parses the command line option and
> replaces stdin and stdout with the correct device, but then in dispnew.c
> it always calls init_tty with 0 as argument for the device name.  That
> simply opens the controlling terminal, i.e. /dev/tty and that is usually
> the same device as the one that GDB uses.
> 
> What would you think of the change below?

I don't think it's the correct change.  For starters, ttyname is
non-portable: on some supported platforms there's no way of getting at
the name of a non-default terminal.

More importantly, we already know the name of the terminal: we used it
in emacs.c when we processed the --terminal switch.  We just "forgot"
it because we didn't save it anywhere.  So one way of fixing this is
to record that name and reuse it in init_tty.  E.g., make DEV_TTY
non-const, and save the actual name there when we process it in
emacs.c.

Adding Paul in case he has comments.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Helmut Eller]

On Tue, Apr 23 2024, Eli Zaretskii wrote:

>> I'd like to start Emacs under GDB, but so that Emacs doesn't use the
>> same terminal as GDB.
>
> You should be able to do that with GDB features.  These include:
>
>   . the 'set inferior-tty' command
>   . the 'set new-console' command
>
> The first sets the terminal of the debuggee to the named terminal, the
> latter causes GDB to create a new terminal each time you "run" a
> debuggee, and force the debuggee to use that new terminal.  These
> commands should work for you without any changes to the Emacs sources.
>
> Alternatively, you could start GDB from a different terminal and
> attach it to an already running Emacs, but this does not allow you to
> debug the Emacs startup code.

Yes, I will use that.  That's much easier than improving a feature that
apparently nobody uses.  You can close this bug.

Helmut

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Eli Zaretskii]

> Cc: 70519@debbugs.gnu.org
> Date: Tue, 23 Apr 2024 08:32:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> More importantly, we already know the name of the terminal: we used it
> in emacs.c when we processed the --terminal switch.  We just "forgot"
> it because we didn't save it anywhere.  So one way of fixing this is
> to record that name and reuse it in init_tty.  E.g., make DEV_TTY
> non-const, and save the actual name there when we process it in
> emacs.c.

I attempted to fix this now that way on the master branch.  Would you
mind testing whether it does what you wanted?  If the current master
somehow doesn't do what you wanted, I'd appreciate a recipe for
reproducing the problematic behavior, so I could investigate.

Thanks.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Helmut Eller]

On Sat, May 04 2024, Eli Zaretskii wrote:

>> Cc: 70519@debbugs.gnu.org
>> Date: Tue, 23 Apr 2024 08:32:25 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> More importantly, we already know the name of the terminal: we used it
>> in emacs.c when we processed the --terminal switch.  We just "forgot"
>> it because we didn't save it anywhere.  So one way of fixing this is
>> to record that name and reuse it in init_tty.  E.g., make DEV_TTY
>> non-const, and save the actual name there when we process it in
>> emacs.c.
>
> I attempted to fix this now that way on the master branch.  Would you
> mind testing whether it does what you wanted?  If the current master
> somehow doesn't do what you wanted, I'd appreciate a recipe for
> reproducing the problematic behavior, so I could investigate.

It's much better now.  However, there is still something I would like to
be different.  I basically do this:

1) Start an xterm: xterm -e sh -c 'tty; exec sleep inf'
   This displays /dev/pts/12 and waits.  Let's call this terminal A.

2) Start Emacs in another terminal, let's call it terminal B, start
   Emacs with: emacs -t /dev/pts/12

   This prints "Using /dev/pts/12" and Emacs displays stuff in terminal
   A.  Which is what one would expect.

3) Now when I press C-c in terminal B, I see ^C.  This is not what I
   expect. I would expect that Emacs is interrupted and exits the same
   way a GUI Emacs exits when pressing C-c.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 70519@debbugs.gnu.org
> Date: Sat, 04 May 2024 17:47:00 +0200
> 
> On Sat, May 04 2024, Eli Zaretskii wrote:
> 
> > I attempted to fix this now that way on the master branch.  Would you
> > mind testing whether it does what you wanted?  If the current master
> > somehow doesn't do what you wanted, I'd appreciate a recipe for
> > reproducing the problematic behavior, so I could investigate.
> 
> It's much better now.  However, there is still something I would like to
> be different.  I basically do this:
> 
> 1) Start an xterm: xterm -e sh -c 'tty; exec sleep inf'
>    This displays /dev/pts/12 and waits.  Let's call this terminal A.
> 
> 2) Start Emacs in another terminal, let's call it terminal B, start
>    Emacs with: emacs -t /dev/pts/12
> 
>    This prints "Using /dev/pts/12" and Emacs displays stuff in terminal
>    A.  Which is what one would expect.
> 
> 3) Now when I press C-c in terminal B, I see ^C.  This is not what I
>    expect. I would expect that Emacs is interrupted and exits the same
>    way a GUI Emacs exits when pressing C-c.

Thanks for testing.  I'm not sure about item 3, I guess it has
something to do with the controlling terminal and how signals are
delivered depending on that.  AFAIU, the --terminal option causes
Emacs to close its original stdin, so Ctrl-C does not send SIGINT to
Emacs.  But I'm nowhere near being an expert on that.  Paul, can you
please comment on that?

In any case, does this allow you to do what you originally wanted,
i.e. debug a -nw session of Emacs without mixing GDB I/O and Emacs
I/O?

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Helmut Eller]

On Sat, May 04 2024, Eli Zaretskii wrote:

> In any case, does this allow you to do what you originally wanted,
> i.e. debug a -nw session of Emacs without mixing GDB I/O and Emacs
> I/O?

Yes. Though, at the moment I'm testing mostly GUI stuff.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  70519@debbugs.gnu.org
> Date: Sat, 04 May 2024 18:25:32 +0200
> 
> On Sat, May 04 2024, Eli Zaretskii wrote:
> 
> > In any case, does this allow you to do what you originally wanted,
> > i.e. debug a -nw session of Emacs without mixing GDB I/O and Emacs
> > I/O?
> 
> Yes. Though, at the moment I'm testing mostly GUI stuff.

Good, thanks.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Paul Eggert]

On 2024-05-04 09:19, Eli Zaretskii wrote:
> AFAIU, the --terminal option causes
> Emacs to close its original stdin, so Ctrl-C does not send SIGINT to
> Emacs.  But I'm nowhere near being an expert on that.  Paul, can you
> please comment on that?

Closing stdin doesn't change a process's controlling terminal. On 
GNU/Linux you need to use ioctl with TIOCSCTTY and there are a bunch of 
other preconditions. See how emacs_spawn uses TIOCSCTTY:

        /* We ignore the return value
           because faith@cs.unc.edu says that is necessary on Linux.  */
        ioctl (std_in, TIOCSCTTY, 0);

This comment (and ignoring ioctl's return value) was added by rms in 
commit 084fd64ac9daee2a89d393f07ce87ec8df543330 dated 1993. I'm 
skeptical that the comment is true now. You might try adding code to 
check the return value and report any errors, though Emacs shouldn't 
abort (as it did before that 1993 change) if the ioctl fails.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Eli Zaretskii]

> Date: Sat, 4 May 2024 09:36:23 -0700
> Cc: 70519@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-05-04 09:19, Eli Zaretskii wrote:
> > AFAIU, the --terminal option causes
> > Emacs to close its original stdin, so Ctrl-C does not send SIGINT to
> > Emacs.  But I'm nowhere near being an expert on that.  Paul, can you
> > please comment on that?
> 
> Closing stdin doesn't change a process's controlling terminal. On 
> GNU/Linux you need to use ioctl with TIOCSCTTY and there are a bunch of 
> other preconditions. See how emacs_spawn uses TIOCSCTTY:
> 
>         /* We ignore the return value
>            because faith@cs.unc.edu says that is necessary on Linux.  */
>         ioctl (std_in, TIOCSCTTY, 0);

So you are saying that the handling of --terminal in emacs.c is
incomplete, in that it doesn't call that ioctl on the new stdin?
because according to these comments in term.c, we do want the new
terminal to become our controlling terminal:

  /* Create a termcap display on the tty device with the given name and
     type.

     If NAME is NULL, then use the controlling tty, i.e., dev_tty.
     Otherwise NAME should be a path to the tty device file,
     e.g. "/dev/pts/7".
  [...]
  #ifndef DOS_NT
    if (!strcmp (name, dev_tty))
      ctty = 1;
  #endif
  [...]
      /* Open the terminal device.  */

      /* If !ctty, don't recognize it as our controlling terminal, and
	 don't make it the controlling tty if we don't have one now.

	 Alas, O_IGNORE_CTTY is a GNU extension that seems to be only
	 defined on Hurd.  On other systems, we need to explicitly
	 dissociate ourselves from the controlling tty when we want to
	 open a frame on the same terminal.  */
      int flags = O_RDWR | O_NOCTTY | (ctty ? 0 : O_IGNORE_CTTY);
      int fd = emacs_open (name, flags, 0);
      tty->input = tty->output
	= ((fd < 0 || ! isatty (fd))
	   ? NULL
	   : emacs_fdopen (fd, "w+"));
  [...]
      if (!O_IGNORE_CTTY && !ctty)
	dissociate_if_controlling_tty (fd);

In any case, is the result Helmut reports after typing Ctrl-C
expected, or does it mean we have a bug when using --terminal?

> This comment (and ignoring ioctl's return value) was added by rms in 
> commit 084fd64ac9daee2a89d393f07ce87ec8df543330 dated 1993. I'm 
> skeptical that the comment is true now. You might try adding code to 
> check the return value and report any errors, though Emacs shouldn't 
> abort (as it did before that 1993 change) if the ioctl fails.

But emacs_spawn is about starting a sub-process, which is something
different from what I'm talking about.  Here, the issue is the Emacs's
own terminal.

Thanks.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Paul Eggert]

On 2024-05-04 10:19, Eli Zaretskii wrote:

> So you are saying that the handling of --terminal in emacs.c is
> incomplete, in that it doesn't call that ioctl on the new stdin?

Sounds like that may be so, if that's what Helmut needs.


> In any case, is the result Helmut reports after typing Ctrl-C
> expected, or does it mean we have a bug when using --terminal?

I don't know. I don't use --terminal. Perhaps others who use it could 
weigh in.


> emacs_spawn is about starting a sub-process, which is something
> different from what I'm talking about.  Here, the issue is the Emacs's
> own terminal.

This stuff used to be in different and somewhat-duplicated sections of 
code, but Philipp refactored and coalesced this in 2020. Perhaps a bit 
of the controlling terminal business got lost in the shuffle? I'll cc 
this to Philipp to see whether he has insight on the issue. Philipp, the 
details are here:

https://bugs.gnu.org/70519

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Andreas Schwab]

On Mai 04 2024, Helmut Eller wrote:

> 3) Now when I press C-c in terminal B, I see ^C.  This is not what I
>    expect. I would expect that Emacs is interrupted and exits the same
>    way a GUI Emacs exits when pressing C-c.

Why do you expect that?  You have told Emacs to use a different
terminal, and a process can only have a single controlling terminal.  It
is unusual for GUI processes to have controlling terminals.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Helmut Eller]

> On Mai 04 2024, Helmut Eller wrote:
>
>> 3) Now when I press C-c in terminal B, I see ^C.  This is not what I
>>    expect. I would expect that Emacs is interrupted and exits the same
>>    way a GUI Emacs exits when pressing C-c.
>
> Why do you expect that?  You have told Emacs to use a different
> terminal, and a process can only have a single controlling terminal.  It
> is unusual for GUI processes to have controlling terminals.

I expect that so that I can press C-c in terminal B to interrupt and
exit Emacs like in GUI mode.

bug#70519: 30.0.50; Device for Emacs terminal I/O

[Andreas Schwab]

On Mai 04 2024, Helmut Eller wrote:

>> On Mai 04 2024, Helmut Eller wrote:
>>
>>> 3) Now when I press C-c in terminal B, I see ^C.  This is not what I
>>>    expect. I would expect that Emacs is interrupted and exits the same
>>>    way a GUI Emacs exits when pressing C-c.
>>
>> Why do you expect that?  You have told Emacs to use a different
>> terminal, and a process can only have a single controlling terminal.  It
>> is unusual for GUI processes to have controlling terminals.
>
> I expect that so that I can press C-c in terminal B to interrupt and
> exit Emacs like in GUI mode.

Why do you expect that?  You have told Emacs to use a different
terminal, and a process can only have a single controlling terminal.  It
is unusual for GUI processes to have controlling terminals.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."