python and vc numbers

[Daniel Dalton]

Hi,

I have a very simple problem, but I can't work out the answer. How do I
return the current tty number in python? eg. what function/module should
I use to figure out what tty my program was invoked from?

Thanks

--
Cheers,
Dan

http://members.iinet.net.au/~ddalton/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksSKNcACgkQQCYsNYjKJVBh9QCgg2ikSkEJIua5wjaptxshpJ8s
7pwAn0lqc8A7ZyosWVPZCykOB/X2bmiM
=aNf4
-----END PGP SIGNATURE-----

 

[Gregory Ewing]

what function/module should
I use to figure out what tty my program was invoked from?

Here's one way:

% python
Python 2.5 (r25:51908, Apr 8 2007, 22:22:18)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.'/dev/ttyp1\n'

 

[Daniel Dalton]

I use to figure out what tty my program was invoked from?

Here's one way:

% python
Python 2.5 (r25:51908, Apr 8 2007, 22:22:18)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

That did the trick, thanks, after I append
[-2]
It works great.

Thanks

Dan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEUEARECAAYFAksTgGsACgkQQCYsNYjKJVB4pgCgvO7NVPd82Vu7EftOH3Ee+Jrq
DOMAmNzvjobd5cMuu7Chfr4m7Tgta2k=
=gbCl
-----END PGP SIGNATURE-----

 

[Daniel Dalton]

That did the trick, thanks, after I append
[-2]

Further testing under screen says otherwise -- it seems to give me the
tty number, not the virtual console number. Is there any way to figure
out what virtual console I'm am in so a certain command ran under screen
process A isn't confused with a command ran under screen process B?

Thanks
Dan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksTmBgACgkQQCYsNYjKJVC2dgCgjH+KUDQFyhoTEFLrUR8xG5Qf
heEAn0QI1CCcCw+u0DtobkGBXQzo0psb
=GAcW
-----END PGP SIGNATURE-----

 

[Chris Rebert]

That did the trick, thanks, after I append
[-2]

Further testing under screen says otherwise -- it seems to give me the
tty number, not the virtual console number. Is there any way to figure
out what virtual console I'm am in so a certain command ran under screen
process A isn't confused with a command ran under screen process B?

From what I can find, virtual console == tty.

Quoting http://en.wikipedia.org/wiki/Virtual_console_(PC)
"The virtual consoles are represented by device special files
/dev/tty1, /dev/tty2 etc."

Also, in my quickie newbie experimentation with `screen`, each screen
"window" seems to get a unique tty#. Admittedly I am running OS X
here, so if your notion of "virtual console" differs from Wikipedia's
and is Linux-specific or something...

Perhaps if you could explain your problem in greater detail?

Cheers,
Chris

 

[Daniel Dalton]

Also, in my quickie newbie experimentation with `screen`, each screen
"window" seems to get a unique tty#. Admittedly I am running OS X

Correct
(Which creates the problem)

Perhaps if you could explain your problem in greater detail?

Sure, well, first I am running screen in a console. Under screen I open
many windows, but in my .screenrc file, after 15 minutes screen runs
screen lock
which is the equivalent of /usr/local/bin/lock
/usr/local/bin/lock is my python script, basically it checks to see if
file /tmp/.vlock.run exists and if it does, will not run vlock again,
but if it doesn't then passes onto vlock. When vlock returns a clean
exit, eg. the user unlocks the term, my program removes that statefile
and exits nicely. (the purpose of this is so screen doesn't lock the
system hundreds of times, asking for a password hundreds of times, or
when using -na it doesn't create a bunch of useless blank "lock" windows
in my screen session.
This works well, but it is only useful for one tty,
because if you lock tty1 then it blocks tty2 etc. I know I could have a
bunch of different scripts using different files, but this just gets to
complicated to manage, so the logical solution is to append vc number to
the filename:
/tmp/.vlock.run.1
/tmp/.vlock.run.2
etc
So we can identify which consoles have been locked, and which
haven't. The problem lies with the fact, I can't find a reliable way to
determine the current console number with python or any bash tool. When
I say console number, I mean the actual console number, not screen
window or device it is sending to or whatever.

I am totally blind, and therefore use a package called brltty, and this
package has the ability to show me what number console I'm in, and even
under screen always works reliably and consistently. So anyone know of a
better solution, now I have described the issue in great detail?

Thanks very much for all the help.

Cheers,
Dan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksTpu4ACgkQQCYsNYjKJVAXKwCfYieoTWlbNKiTAnJijXzOKfsJ
V88An3jjgUFWezOAl41EXUysvwR/WlnD
=S8dp
-----END PGP SIGNATURE-----

 

[Lie Ryan]

Can you make do with the tempfile module? Or you'd need to identify from
an external process which console is locked?

 

[Gregory Ewing]

I can't find a reliable way to
determine the current console number with python or any bash tool. When
I say console number, I mean the actual console number, not screen
window or device it is sending to or whatever.

You may be able to tell by looking at the DISPLAY
environment variable. Usually it has a form like

localhost:X.Y

where X and Y are numbers identifying the display
device and screen.

 

[Nobody]

That did the trick, thanks, after I append
[-2]

Further testing under screen says otherwise -- it seems to give me the
tty number, not the virtual console number. Is there any way to figure
out what virtual console I'm am in

I'm sure that there are all kinds of heuristics you could try, but
ultimately the question is meaningless.

E.g. you can start a screen session on one terminal (which may not be a
VC, but an xterm, ssh login, etc), detach it, attach it to a different
terminal, or even attach it to multiple terminals.

The child process only knows about its controlling terminal. If that
happens to be a pty slave, you could try looking for any processes
connected to the pty master. But you aren't guaranteeed to find any such
processes; if a process is running under a different account, you won't
be able to enumerate its descriptors. And you might find that the
master is owned by e.g. sshd, in which case there really isn't any way to
find out what's on the other end of the connection.

If the process happens to be part of a "screen" session, you can use
"screen -ls" to list sessions, and find out which terminal they are
attached to (although they might be detached, or they might be attached to
something other than a VC).

 

[Daniel Dalton]

Can you make do with the tempfile module? Or you'd need to identify

from an external process which console is locked?

Perhaps, I wrote a small hack:
- Manually set environment variable TTYNUMBER in .bash_profile
- Then use this in the script, to establish what tty I'm working with.

Thanks

--
Cheers,
Dan

http://members.iinet.net.au/~ddalton/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksU94IACgkQQCYsNYjKJVDewQCgu+tD6KfccDEoUuO2y1YGBM2X
2c8AoMKxcTqSyg3Y6tysz6gVBEVv7gmO
=LtVk
-----END PGP SIGNATURE-----