Hi! I just stumbled about an interesting phenomena:
I tried some new/modified scripts via remote ssh access. As part of the script debugging I put in some diagnostic messages. One of those the output of the "tty" command. All previous tests in other environments gave me an expected "/dev/pts/N" but suddenly I got "not a tty". My first assumption was that dropbear did not allocate a pty but after several tries the GNU tty still printed "/dev/pts/N" where Busybox tty responded "not a tty". So I tried to look at the code of GNU tty and Busybox tty and couldn't find a significant difference. So where had the required tty name gone? A comparison of strace output of both GNU and Busybox tty call revealed a big difference. The Busybox version has been compiled with uClibc. And that one tries to search the /dev directory for an entry matching the major/minor device number where the GNU version just read the symlink at /proc/self/fd/2. So the reason why Busybox neglected to respond with the pty name was, I dropped the read permission of the /dev/pts and gave only execute permission to that directory. So it is not a Busybox bug, but it took me some hours of searching for the problem. I don't think that it is a good decision to search the /dev directory for a matching entry where that information is available from a simple readlink(/proc/self/fd/0). So if anybody is able to forward this to the uClibc developers it would be very nice. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
