[SOLVED] shell command to determine which v/tty I'm on right now? (i.e. VT1, VT2 ... )

GazL · 08-05-2010, 02:35 PM

I got interested in this, so I had a little play (more fun than a crossword

).

See what you think of this one:

Code:

#!/bin/bash
#
#  Return tty for this console.
#    When run from an xterm on an X11 display, returns tty of XServer.

read user tty date time display < <( who -m )

if [ "$display" = "" ] ; then
   where="$tty"
else
   where="${display%.*}"
   where="${where#*:}"
   X_pid=$(< "/tmp/.X${where}-lock")
   where=$( ps h -p "${X_pid}" -o tty)
fi

echo "Here is: $where"

Appears to work with multiple active X sessions, started from either KDM or startx and works direct from an xterm or "su -" in an xterm.

GrapefruiTgirl · 08-05-2010, 03:06 PM

Okies

I copied & pasted the file exactly. Here's what happens:

Code:

# first just try it:
root@reactor: sh gazl
gazl: line 6: syntax error near unexpected token `<'
gazl: line 6: `read user tty date time display < <( who -m )'

# Hmm.. try that line directly in the shell (works fine):
root@reactor: read user tty date time display < <( who -m )
root@reactor:

# execute script with Bash explicitly:
root@reactor: bash gazl
gazl: line 13: /tmp/.X41 (:0-lock: No such file or directory
ERROR: List of process IDs must follow -p.
********* simple selection *********  ********* selection by list *********
-A all processes                      -C by command name
< ..snip.. >

Seems to be some shell-related problems

- here's my bash:

Code:

sasha@reactor: bash --version
GNU bash, version 4.1.7(2)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sasha@reactor:

P.S. - Yes! More fun than crosswords, though I prefer cryptograms over crosswords

GazL · 08-05-2010, 03:34 PM

The "< <( )" is a bashism. So yes, I understand that issue. It's needed because bash runs pipelines in a subshell so you can't do

Code:

who -m | read user tty date time display

as you would have done in the more traditional shells.

The quotes around ${X_pid} on the ps h -p seem to be upsetting it for some reason take them off and that fixes it on my box (I must have added them after I last ran it - sorry about that)

What output does your who -m give you? It seems to be getting the name of the lock file wrong on your box, though it works here just fine, so I'm a little bit puzzled on that one.

GrapefruiTgirl · 08-05-2010, 03:39 PM

Here's what `who -m` gives me:

Code:

sasha@reactor: who -m
sasha    pts/2        Aug  5 15:13 (:0.0)
sasha@reactor: su -
Password:
 
root@reactor: who -m
sasha    pts/2        Aug  5 15:13 (:0.0)
root@reactor:

Currently, I can't find a *lock* file anywhere

but still looking.

EDIT: Here it is:

Code:

/tmp/.X0-lock

GazL · 08-05-2010, 03:57 PM

Ahh ha! Here's mine

Code:

gazl@nix:~$ who -m
gazl     pts/3        2010-08-05 21:18 (:0.0)
gazl@nix:~$ bash -x whichVT.sh 
+ read user tty date time display
++ who -m
+ '[' '(:0.0)' = '' ']'
+ where='(:0'
+ where=0
+ X_pid='      1824'
++ ps h -p 1824 -o tty
+ where=tty7
+ echo 'Here is: tty7'
Here is: tty7
gazl@nix:~$

That explains why the quotes were upsetting the ps. There's some leading spaces that need to be dealt with if you quote, but work by accident if you don't.

Your who -m is outputting a different date format to mine, which is why it's failing.

This should fix that.

Version2:

Code:

#!/bin/bash
#
#  Return tty for this console.
#    When run from an xterm on an X11 display, returns tty of XServer.

read user tty month day time display < <( LANG=C who -m )

if [ "$display" = "" ] ; then
   where="$tty"
else
   where="${display%.*}"
   where="${where#*:}"
   read X_pid < "/tmp/.X${where}-lock"
   where=$( ps h -p "${X_pid}" -o tty)
fi

echo "Here is: $where"

Well, that turned out to be even more interesting than I thought.

GrapefruiTgirl · 08-05-2010, 03:58 PM

Let's try this new version

... Back momentarily.

Well, that works nicely! Works from an xterm, and a VT, and also from an xterm on a second X session.

As before, I have to explicitly execute it with "bash" due to the bashisms, so portability will be a problem. However, it is definitely shorter and less overhead than my solution above.

I appreciate the effort you've made - there are a few methods of doing things there which I don't often use, but when I see them I am reminded that I should learn some other ways of doing stuff than I usually use; particularly the variable substitutions and the way you've used `read`.

If you're inclined, I'd love to see this code be portable

but if not, no problem!

Thanks,
Sasha

GazL · 08-05-2010, 04:21 PM

It's trivial to change it to sh

Code:

#!/bin/sh
#
#  Return tty for this console.
#    When run from an xterm on an X11 display, returns tty of XServer.

read user tty month day time display <<_EOD
$(LANG=C who -m)
_EOD

if [ "$display" = "" ] ; then
   where="$tty"
else
   where="${display%.*}"
   where="${where#*:}"
   read X_pid < "/tmp/.X${where}-lock"
   where=$( ps h -p "${X_pid}" -o tty)
fi

echo "Here is: $where"

GrapefruiTgirl · 08-05-2010, 04:25 PM

Excellent! Yes, easier than I'd have thought (I'm automatically leary of all fancy shell substitution stuff not working in non-bash shells) and it works in Dash shell too.

Nice, and thanks again

I think that'll replace my current code, and gets you a credit in the next version of my suspend script (I wonder if anyone still uses it besides myself?

)

Cheers!

GazL · 08-05-2010, 05:07 PM

You're welcome, Sasha. I enjoy these little puzzles. Keeps my hand in.

The "command | read var" pipeline thing is a bit of a nightmare as it varies wildly between shells and even between version of shells.

Using the 'here document' containing the command substitution looks a little funky but it does seem to be fairly portable.

I tend to spend more time on linux than other UNIX these days so I've started using bash a lot more than I used to. I'll have to get myself out of the habit before I fall completely to the dark-side.

GrapefruiTgirl · 08-05-2010, 05:36 PM

Agreed about the | pipeline thing. That has given me grief several times that I can recall. But, on any given instance, usually one of either the pipe inwards, or the < at the end, works. When both of those fail sometime, I'll be Googling again or referring to the Bash FAQ again.

As for the here docs, they may look weird with commands embedded in them, but it's always worked for me.

I'm going to leave both versions of this function inside the suspend script (if for no other reason than my own reference): my version, which has a bad case of grep-itis and pipe-itis, will be commented out; and yours uncommented as the default, as it's very neat & efficient and should work reliably until the Xorg people change the location of the lock file :/ LOL. I'll post the updated version of the script shortly.

All the best,
Sasha