Re: Possible problem with GNU libc & Linux 2.2.X ? (fwd)

[Jan Rafaj <Jan dot Rafaj at cedric dot vabo dot cz>]

Hello,

First, I'm sorry for this later reply. I've found where the problem
resides, already. There's NO such bug (mentioned below) in GNU libc
(accept my apology for this noise, please)..

The problem exists with "pdmenu" menuing shell. It actually opens
"/dev/tty" instead of "/dev/tty*" device, hence all the child
processes (f.e. bourne shell) will actually use that device
for stdin/out.

The mentioned problem appears when someone doesn't use
Unix98 PTYs, uses "pdmenu" as the login-shell, starts a real shell
from its menu, and tries to use f.e. screen, which relies
on (re)opening /dev/tty?* device ("screen -r" won't work in this case,
for non-root user).

A simple patch for "pdmenu" attached below fixes this behaviour
for non-Unix98 PTY-equipped Linuxes.

Regards,

Jan


On 13 Sep 2000, James Antill wrote:

> Jan Rafaj <Jan.Rafaj@cedric.vabo.cz> writes:
> 
> > Recently, while trying to get a program to work on system equipped
> > with Linux 2.2.17, configured NOT TO USE Unix98 ttys, and glibc-2.1.3,
> > I've faced this problem:
> > 
> > The function ttyname(0) returns just "/dev/tty" for ordinary user,
> > while for root, it returns the real tty he's connected through.
> 
>  I'm using glibc-2.1.3 and Linux-2.1.17, but not using Unix98 ttys.
> 
>  The program...
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> 
> int main(void)
> {
> 
>  printf("%s\n", ttyname(0));
> 
>  exit (EXIT_SUCCESS);
> }
> 
>  Prints...
> /dev/ttyp4
> 
>  And ls -l /proc/self/fd/0 prints...
> lrwx------   1 james    users          64 Sep 13 16:02 /proc/self/fd/0 -> /dev/ttyp4
> 
>  I'm not using a distribution though, what does the ls command above
> show for you ?
> 
> -- 
> James Antill -- james@and.org
>

pdmenu_1.2.64-whichtty.diff.gz