Re: Opinions solicted for changes to tty names in 1.7.10
On Sun, Jul 03, 2011 at 11:32:56AM +0200, Corinna Vinschen wrote: >On Jul 2 19:43, Christopher Faylor wrote: >> On Sat, Jul 02, 2011 at 06:42:04AM +0100, Andy Koppe wrote: >> >Hmm, the two-character ut_id would actually be a problem with Unix98 >> >ptys, because according to Linux's 'man utmp' it's supposed to be 'p' >> >followed by the pts number there. This would only allow for 10 ptys. >> > >> >How about going with the BSD scheme as previously used on Linux? >> >Should be much less work than Unix98 ptys as well. >> > >> >consoles: ttyN >> >pty masters: /dev/pty[p-za-e][0-9a-f] >> >pty slaves: /dev/tty[p-za-e][0-9a-f] >> > >> >The [p-za-e][0-9a-f] encoding allows for up to 256 pseudo terminal >> >pairs and fits into ut_id. >> >> If it boils down to making the tty number look more like linux >> (/dev/pts/10) or just puting a "10" in ut_id, I'd opt for just putting >> the "10" there. The "p" really wouldn't make any sense for Cygwin since >> we no longer have ttys. > >But how do you differ between console 10 and tty 10? The BSD/old-Linux >naming scheme seems a good way to accomplish that. AFAIK, in Cygwin, console programs have never used these fields, unless you go went of your way to call login(1) from a console. And, in that case, old Cygwin filled out the field essentially with garbage. The old CYGWIN=tty code used to update /var/run/utmp and /var/run/wtmp but that should be gone now. Given that the ut_id field can contain arbitrary data and since its length means that we can't fully emulate linux anyway, I'm comfortable with just putting two digits there. There is really no ambiguity since the ut_line field makes it clear which device is being used. One reason that I like /dev/pts is that it makes it easy to write a "driver" which allows you to do "ls /dev/pts" to see which ptys are in use. You can't really do that for /dev/[pt]ty* without implementing a full devfs. You could, of course, detect "[pt]tty*" as a special case, but that would be wrong. cgf
Re: Opinions solicted for changes to tty names in 1.7.10
On Jul 2 19:43, Christopher Faylor wrote: > On Sat, Jul 02, 2011 at 06:42:04AM +0100, Andy Koppe wrote: > >Hmm, the two-character ut_id would actually be a problem with Unix98 > >ptys, because according to Linux's 'man utmp' it's supposed to be 'p' > >followed by the pts number there. This would only allow for 10 ptys. > > > >How about going with the BSD scheme as previously used on Linux? > >Should be much less work than Unix98 ptys as well. > > > >consoles: ttyN > >pty masters: /dev/pty[p-za-e][0-9a-f] > >pty slaves: /dev/tty[p-za-e][0-9a-f] > > > >The [p-za-e][0-9a-f] encoding allows for up to 256 pseudo terminal > >pairs and fits into ut_id. > > If it boils down to making the tty number look more like linux > (/dev/pts/10) or just puting a "10" in ut_id, I'd opt for just putting > the "10" there. The "p" really wouldn't make any sense for Cygwin since > we no longer have ttys. But how do you differ between console 10 and tty 10? The BSD/old-Linux naming scheme seems a good way to accomplish that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Opinions solicted for changes to tty names in 1.7.10
On Sat, Jul 02, 2011 at 06:42:04AM +0100, Andy Koppe wrote:
>On 15 June 2011 21:52, Christopher Faylor wrote:
>> On Wed, Jun 15, 2011 at 09:46:24PM +0100, Andy Koppe wrote:
>>>On 15 June 2011 15:55, Christopher Faylor wrote:
On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote:
>On 14 June 2011 21:36, Christopher Faylor wrote:
>> After some discussion with Corinna, I'm thinking about making a change to
>> the tty naming in Cygwin as part of the removal of CYGWIN=tty.
>>
>> (In case you haven't noticed, CYGWIN=tty, is no longer supported in
>> snapshots. ??If you do have the tty option set you get one warning per
>> session telling you to unset it.)
>>
>> Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
>> like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN
>> support for consoles but I'd like to change that so that consoles are
>> represented as /dev/ttyN instead.
>
>Makes plenty of sense.
>
>The only concern I see is that BSD PTYs (as previously used on Linux
>as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
>whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
>calling the slave side "ptyN" could conceivably cause issues.
>
>Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
>out of the question?
No. ??I considered that but adding an arbitrary directory structure under
out /dev kludge seemed wrong. ??I would prefer to make it look more like
Linux though. ??The man reason why I didn't implement that is that I
thought someone would report that "ls /dev/pts" doesn't work
>>>
>>>Good point. Unlike "ls /dev/pty*", it would actually be useful as it's
>>>supposed to contain the currently used ptys.
>>>
not that it couldn't be made to work.
>>>
>>>That would be nice.
>>
>> I agree. ??So, I guess I'll look into what it would take to implement
>> that and hold off the renaming for now.
>>
>>>The terminal is supposed to cut off all of "/dev/tty", especially as
>>>Cygwin's ut_id is only 2 chars, whereas Linux's is 4.
>>
>> Oh right. ??I knew that.
>
>Hmm, the two-character ut_id would actually be a problem with Unix98
>ptys, because according to Linux's 'man utmp' it's supposed to be 'p'
>followed by the pts number there. This would only allow for 10 ptys.
>
>How about going with the BSD scheme as previously used on Linux?
>Should be much less work than Unix98 ptys as well.
>
>consoles: ttyN
>pty masters: /dev/pty[p-za-e][0-9a-f]
>pty slaves: /dev/tty[p-za-e][0-9a-f]
>
>The [p-za-e][0-9a-f] encoding allows for up to 256 pseudo terminal
>pairs and fits into ut_id.
If it boils down to making the tty number look more like linux
(/dev/pts/10) or just puting a "10" in ut_id, I'd opt for just putting
the "10" there. The "p" really wouldn't make any sense for Cygwin since
we no longer have ttys.
cgf
Re: Opinions solicted for changes to tty names in 1.7.10
On 15 June 2011 21:52, Christopher Faylor wrote:
> On Wed, Jun 15, 2011 at 09:46:24PM +0100, Andy Koppe wrote:
>>On 15 June 2011 15:55, Christopher Faylor wrote:
>>> On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote:
On 14 June 2011 21:36, Christopher Faylor wrote:
> After some discussion with Corinna, I'm thinking about making a change to
> the tty naming in Cygwin as part of the removal of CYGWIN=tty.
>
> (In case you haven't noticed, CYGWIN=tty, is no longer supported in
> snapshots. ??If you do have the tty option set you get one warning per
> session telling you to unset it.)
>
> Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
> like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN
> support for consoles but I'd like to change that so that consoles are
> represented as /dev/ttyN instead.
Makes plenty of sense.
The only concern I see is that BSD PTYs (as previously used on Linux
as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
calling the slave side "ptyN" could conceivably cause issues.
Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
out of the question?
>>>
>>> No. ??I considered that but adding an arbitrary directory structure under
>>> out /dev kludge seemed wrong. ??I would prefer to make it look more like
>>> Linux though. ??The man reason why I didn't implement that is that I
>>> thought someone would report that "ls /dev/pts" doesn't work
>>
>>Good point. Unlike "ls /dev/pty*", it would actually be useful as it's
>>supposed to contain the currently used ptys.
>>
>>> not that it couldn't be made to work.
>>
>>That would be nice.
>
> I agree. So, I guess I'll look into what it would take to implement
> that and hold off the renaming for now.
>
>>The terminal is supposed to cut off all of "/dev/tty", especially as
>>Cygwin's ut_id is only 2 chars, whereas Linux's is 4.
>
> Oh right. I knew that.
Hmm, the two-character ut_id would actually be a problem with Unix98
ptys, because according to Linux's 'man utmp' it's supposed to be 'p'
followed by the pts number there. This would only allow for 10 ptys.
How about going with the BSD scheme as previously used on Linux?
Should be much less work than Unix98 ptys as well.
consoles: ttyN
pty masters: /dev/pty[p-za-e][0-9a-f]
pty slaves: /dev/tty[p-za-e][0-9a-f]
The [p-za-e][0-9a-f] encoding allows for up to 256 pseudo terminal
pairs and fits into ut_id.
Andy
Re: Opinions solicted for changes to tty names in 1.7.10
On Wed, Jun 15, 2011 at 09:46:24PM +0100, Andy Koppe wrote:
>On 15 June 2011 15:55, Christopher Faylor wrote:
>> On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote:
>>>On 14 June 2011 21:36, Christopher Faylor wrote:
After some discussion with Corinna, I'm thinking about making a change to
the tty naming in Cygwin as part of the removal of CYGWIN=tty.
(In case you haven't noticed, CYGWIN=tty, is no longer supported in
snapshots. ??If you do have the tty option set you get one warning per
session telling you to unset it.)
Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN
support for consoles but I'd like to change that so that consoles are
represented as /dev/ttyN instead.
>>>
>>>Makes plenty of sense.
>>>
>>>The only concern I see is that BSD PTYs (as previously used on Linux
>>>as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
>>>whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
>>>calling the slave side "ptyN" could conceivably cause issues.
>>>
>>>Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
>>>out of the question?
>>
>> No. ??I considered that but adding an arbitrary directory structure under
>> out /dev kludge seemed wrong. ??I would prefer to make it look more like
>> Linux though. ??The man reason why I didn't implement that is that I
>> thought someone would report that "ls /dev/pts" doesn't work
>
>Good point. Unlike "ls /dev/pty*", it would actually be useful as it's
>supposed to contain the currently used ptys.
>
>> not that it couldn't be made to work.
>
>That would be nice.
I agree. So, I guess I'll look into what it would take to implement
that and hold off the renaming for now. I'm going to be gone for two
weeks starting on Friday so this won't happen soon though.
>The terminal is supposed to cut off all of "/dev/tty", especially as
>Cygwin's ut_id is only 2 chars, whereas Linux's is 4.
Oh right. I knew that.
cgf
Re: Opinions solicted for changes to tty names in 1.7.10
On 15 June 2011 15:55, Christopher Faylor wrote:
> On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote:
>>On 14 June 2011 21:36, Christopher Faylor wrote:
>>> After some discussion with Corinna, I'm thinking about making a change to
>>> the tty naming in Cygwin as part of the removal of CYGWIN=tty.
>>>
>>> (In case you haven't noticed, CYGWIN=tty, is no longer supported in
>>> snapshots. ??If you do have the tty option set you get one warning per
>>> session telling you to unset it.)
>>>
>>> Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
>>> like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN
>>> support for consoles but I'd like to change that so that consoles are
>>> represented as /dev/ttyN instead.
>>
>>Makes plenty of sense.
>>
>>The only concern I see is that BSD PTYs (as previously used on Linux
>>as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
>>whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
>>calling the slave side "ptyN" could conceivably cause issues.
>>
>>Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
>>out of the question?
>
> No. I considered that but adding an arbitrary directory structure under
> out /dev kludge seemed wrong. I would prefer to make it look more like
> Linux though. The man reason why I didn't implement that is that I
> thought someone would report that "ls /dev/pts" doesn't work
Good point. Unlike "ls /dev/pty*", it would actually be useful as it's
supposed to contain the currently used ptys.
> not that it couldn't be made to work.
That would be nice.
>>> Corinna suggested that I should send a query here to see if anyone knows
>>> if this proposed change will affect any existing applications which use
>>> ptys like mintty, emacs, xterm, rxvt, or screen.
>>
>>Mintty currently only looks for "tty" when cutting down the device
>>name to fill in the utmp.ut_id field, but that's trivial to change
>>(and utmp isn't on by default anyway).
>
> Shouldn't it just be using basename(3)?
The terminal is supposed to cut off all of "/dev/tty", especially as
Cygwin's ut_id is only 2 chars, whereas Linux's is 4.
Andy
Re: Opinions solicted for changes to tty names in 1.7.10
On 6/14/2011 4:36 PM, Christopher Faylor wrote: Corinna suggested that I should send a query here to see if anyone knows if this proposed change will affect any existing applications which use ptys like mintty, emacs, xterm, rxvt, or screen. Does anyone see any problems with this? I'm pretty sure there will be no problem with emacs. At worst it will have to be rebuilt, but I don't even think that will be necessary. Ken
Re: Opinions solicted for changes to tty names in 1.7.10
On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote:
>On 14 June 2011 21:36, Christopher Faylor wrote:
>> After some discussion with Corinna, I'm thinking about making a change to
>> the tty naming in Cygwin as part of the removal of CYGWIN=tty.
>>
>> (In case you haven't noticed, CYGWIN=tty, is no longer supported in
>> snapshots. ??If you do have the tty option set you get one warning per
>> session telling you to unset it.)
>>
>> Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
>> like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN
>> support for consoles but I'd like to change that so that consoles are
>> represented as /dev/ttyN instead.
>
>Makes plenty of sense.
>
>The only concern I see is that BSD PTYs (as previously used on Linux
>as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
>whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
>calling the slave side "ptyN" could conceivably cause issues.
>
>Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
>out of the question?
No. I considered that but adding an arbitrary directory structure under
out /dev kludge seemed wrong. I would prefer to make it look more like
Linux though. The man reason why I didn't implement that is that I
thought someone would report that "ls /dev/pts" doesn't work - not that
it couldn't be made to work.
>> Corinna suggested that I should send a query here to see if anyone knows
>> if this proposed change will affect any existing applications which use
>> ptys like mintty, emacs, xterm, rxvt, or screen.
>
>Mintty currently only looks for "tty" when cutting down the device
>name to fill in the utmp.ut_id field, but that's trivial to change
>(and utmp isn't on by default anyway).
Shouldn't it just be using basename(3)?
cgf
Re: Opinions solicted for changes to tty names in 1.7.10
On Jun 15 10:33, Charles Wilson wrote: > On 6/14/2011 4:36 PM, Christopher Faylor wrote: > > Corinna suggested that I should send a query here to see if anyone knows > > if this proposed change will affect any existing applications which use > > ptys like mintty, emacs, xterm, rxvt, or screen. > > I think rxvt will break, but I'm sure that can be corrected with an > updated release. As currently configured, the only explicit references > to "/dev/tty" (note: NOT "/dev/ttyN") are in ptytty.c, as part of the > rxvt_control_tty function. This function is basically concerned with > ensuring that the active [pt]ty does NOT have a controlling terminal, so > it opens /dev/tty with O_NOCTTY and does various checks. > > However, rxvt uses openpty() + ttyname() stuff explicitly for all other > purposes. > > rxvt-unicode uses "/dev/tty" in a similar way, as part of its > control_tty() function. As configured, it uses Unix98 stuff (incl. > ptsname(), posix_openpt(), etc) otherwise. "/dev/tty" will not be removed, of course. It's still the name of the controlling terminal of the process. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Opinions solicted for changes to tty names in 1.7.10
On 6/14/2011 4:36 PM, Christopher Faylor wrote: > Corinna suggested that I should send a query here to see if anyone knows > if this proposed change will affect any existing applications which use > ptys like mintty, emacs, xterm, rxvt, or screen. I think rxvt will break, but I'm sure that can be corrected with an updated release. As currently configured, the only explicit references to "/dev/tty" (note: NOT "/dev/ttyN") are in ptytty.c, as part of the rxvt_control_tty function. This function is basically concerned with ensuring that the active [pt]ty does NOT have a controlling terminal, so it opens /dev/tty with O_NOCTTY and does various checks. However, rxvt uses openpty() + ttyname() stuff explicitly for all other purposes. rxvt-unicode uses "/dev/tty" in a similar way, as part of its control_tty() function. As configured, it uses Unix98 stuff (incl. ptsname(), posix_openpt(), etc) otherwise. > Does anyone see any > problems with this? Problems can include large wails of protest from > the user community if you think that will happen. I can't predict if > this will be the case or not. I don't know the purity of doing things > this way will outweigh any end user confusion. Or even if there will > be that much end user confusion. I doubt most end users will care. Maintainers of terminals and shells will -- because those have needed extensive patching in the past, some of those patches may need to be reverted or revised to work with the new scheme. Whether this means existing binaries will break until rebuilt, I'm not sure. We'll just have to see. -- Chuck
Re: Opinions solicted for changes to tty names in 1.7.10
On 14 June 2011 21:36, Christopher Faylor wrote:
> After some discussion with Corinna, I'm thinking about making a change to
> the tty naming in Cygwin as part of the removal of CYGWIN=tty.
>
> (In case you haven't noticed, CYGWIN=tty, is no longer supported in
> snapshots. If you do have the tty option set you get one warning per
> session telling you to unset it.)
>
> Since the only thing using Cygwin's "tty layer" will now be ptys, I'd
> like to rename /dev/ttyN to /dev/ptyN. I've already added /dev/consN
> support for consoles but I'd like to change that so that consoles are
> represented as /dev/ttyN instead.
Makes plenty of sense.
The only concern I see is that BSD PTYs (as previously used on Linux
as well, IIRC) are called "pty[p-za-e][0-9a-f]" on the master side,
whereas they're "tty[p-za-e][0-9a-f]" on the slave side. Therefore
calling the slave side "ptyN" could conceivably cause issues.
Is the Unix98 scheme ("/dev/pts/N") that's used on Linux these days
out of the question?
> Corinna suggested that I should send a query here to see if anyone knows
> if this proposed change will affect any existing applications which use
> ptys like mintty, emacs, xterm, rxvt, or screen.
Mintty currently only looks for "tty" when cutting down the device
name to fill in the utmp.ut_id field, but that's trivial to change
(and utmp isn't on by default anyway).
Andy
Opinions solicted for changes to tty names in 1.7.10
After some discussion with Corinna, I'm thinking about making a change to the tty naming in Cygwin as part of the removal of CYGWIN=tty. (In case you haven't noticed, CYGWIN=tty, is no longer supported in snapshots. If you do have the tty option set you get one warning per session telling you to unset it.) Since the only thing using Cygwin's "tty layer" will now be ptys, I'd like to rename /dev/ttyN to /dev/ptyN. I've already added /dev/consN support for consoles but I'd like to change that so that consoles are represented as /dev/ttyN instead. Obviously ps(1) will need to be changed too. Corinna suggested that I should send a query here to see if anyone knows if this proposed change will affect any existing applications which use ptys like mintty, emacs, xterm, rxvt, or screen. Does anyone see any problems with this? Problems can include large wails of protest from the user community if you think that will happen. I can't predict if this will be the case or not. I don't know the purity of doing things this way will outweigh any end user confusion. Or even if there will be that much end user confusion. cgf
