GNU bug report logs - #70519
30.0.50; Device for Emacs terminal I/O

Previous Next

To reply to this bug, email your comments to 70519 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Device for Emacs terminal I/O
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.  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)

Message #8 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Tue, 23 Apr 2024 08:32:25 +0300

> From: Helmut Eller <eller.helmut <at> 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.

Message #11 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70519 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Tue, 23 Apr 2024 08:09:45 +0200

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

Message #14 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: eller.helmut <at> gmail.com
Cc: 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 13:34:23 +0300

> Cc: 70519 <at> debbugs.gnu.org
> Date: Tue, 23 Apr 2024 08:32:25 +0300
> From: Eli Zaretskii <eliz <at> 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.

Message #17 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 17:47:00 +0200

On Sat, May 04 2024, Eli Zaretskii wrote:

>> Cc: 70519 <at> debbugs.gnu.org
>> Date: Tue, 23 Apr 2024 08:32:25 +0300
>> From: Eli Zaretskii <eliz <at> 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.

Message #20 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 19:19:12 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 70519 <at> 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?

Message #23 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70519 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
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.

Message #26 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Helmut Eller <eller.helmut <at> gmail.com>
Cc: 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 4 May 2024 09:36:23 -0700

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 <at> 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.

Message #29 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 70519 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 20:03:03 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  70519 <at> 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.

Message #32 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 70519 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 20:19:38 +0300

> Date: Sat, 4 May 2024 09:36:23 -0700
> Cc: 70519 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> 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 <at> 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.

Message #35 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, 70519 <at> debbugs.gnu.org,
 eller.helmut <at> gmail.com
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 4 May 2024 10:39:20 -0700

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

Message #38 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 20:19:30 +0200

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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #41 received at 70519 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70519 <at> debbugs.gnu.org
Subject: Re: bug#70519: 30.0.50; Device for Emacs terminal I/O
Date: Sat, 04 May 2024 20:27:42 +0200

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.