Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #197327 > unrolled thread

VT2 for Xorg?

Started byCarl Fink <carlf@panix.com>
First post2018-07-07 22:40 +0200
Last post2018-07-09 16:00 +0200
Articles 7 — 4 participants

Back to article view | Back to linux.debian.user


Contents

  VT2 for Xorg? Carl Fink <carlf@panix.com> - 2018-07-07 22:40 +0200
    Re: VT2 for Xorg? Zenaan Harkness <zenaan@freedbms.net> - 2018-07-08 05:10 +0200
      Re: VT2 for Xorg? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-09 15:10 +0200
        Re: VT2 for Xorg? Dan Ritter <dsr@randomstring.org> - 2018-07-09 15:50 +0200
          Re: VT2 for Xorg? Zenaan Harkness <zenaan@freedbms.net> - 2018-07-09 16:00 +0200
            Re: VT2 for Xorg? Zenaan Harkness <zenaan@freedbms.net> - 2018-07-09 16:00 +0200
        Re: VT2 for Xorg? Zenaan Harkness <zenaan@freedbms.net> - 2018-07-09 16:00 +0200

#197327 — VT2 for Xorg?

FromCarl Fink <carlf@panix.com>
Date2018-07-07 22:40 +0200
SubjectVT2 for Xorg?
Message-ID<w929P-4sk-1@gated-at.bofh.it>
Anyone else have this? Since using the nVidia fix posted to this list, 
Xorg is claiming VT2, not VT7 as usual.

No biggie once I figured it out, but odd.

-- 
Carl Fink          carl@finknetwork.com
Thinking and logic and stuff at Reasonably Literate
http://reasonablyliterate.com

[toc] | [next] | [standalone]


#197338

FromZenaan Harkness <zenaan@freedbms.net>
Date2018-07-08 05:10 +0200
Message-ID<w98ff-8lx-1@gated-at.bofh.it>
In reply to#197327
On Sat, Jul 07, 2018 at 04:35:16PM -0400, Carl Fink wrote:
> Anyone else have this? Since using the nVidia fix posted to this list, Xorg is claiming VT2, not VT7 as usual.
> 
> No biggie once I figured it out, but odd.

When Xorg starts, there's an optional -keeptty

There's also a deallocvt command

With a bash fn like:
  ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }

Then something like this will id your current tty:
  ttyGetNum;  export Xorg_vt=vt$?

I don't have nvidia

Good luck,

[toc] | [prev] | [next] | [standalone]


#197392

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-07-09 15:10 +0200
Message-ID<w9E5r-2oD-1@gated-at.bofh.it>
In reply to#197338
On Sun, Jul 08, 2018 at 01:08:59PM +1000, Zenaan Harkness wrote:
> With a bash fn like:
>   ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }
> 
> Then something like this will id your current tty:
>   ttyGetNum;  export Xorg_vt=vt$?

Ewwwww!

The return status of a shell function is NOT intended to be used this way.
It's analogous to the exit status of a shell command.  It's a single
byte, unsigned, so you can only return 0 to 255.  It's intended to convey
success or failure, not to carry an actual data payload.

I recommend that you switch to using a regular variable for this purpose.
I happen to like "r".  With a regular variable, you're not restricted to
integers from 0 to 255, and you retain the ability to convey succss/failure
through the return code.

As an aside, you can save the call to GNU grep by simply stripping the
leading "/dev/tty" from the output of tty using a shell parameter
expansion:

  ttyGetNum() {
    local t
    t=$(tty) || return 1
    [[ $t = /dev/tty+([0-9]) ]] || return 1
    r=${t#/dev/tty}
  }

  if ttyGetNum; then export Xorg_vt=vt"$r"; fi

[toc] | [prev] | [next] | [standalone]


#197398

FromDan Ritter <dsr@randomstring.org>
Date2018-07-09 15:50 +0200
Message-ID<w9EI9-2Be-3@gated-at.bofh.it>
In reply to#197392
On Mon, Jul 09, 2018 at 09:08:17AM -0400, Greg Wooledge wrote:
> On Sun, Jul 08, 2018 at 01:08:59PM +1000, Zenaan Harkness wrote:
> > With a bash fn like:
> >   ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }
> > 
> > Then something like this will id your current tty:
> >   ttyGetNum;  export Xorg_vt=vt$?
> 
> Ewwwww!
> 
> The return status of a shell function is NOT intended to be used this way.
> It's analogous to the exit status of a shell command.  It's a single
> byte, unsigned, so you can only return 0 to 255.  It's intended to convey
> success or failure, not to carry an actual data payload.
> 
> I recommend that you switch to using a regular variable for this purpose.
> I happen to like "r".  With a regular variable, you're not restricted to
> integers from 0 to 255, and you retain the ability to convey succss/failure
> through the return code.
> 
> As an aside, you can save the call to GNU grep by simply stripping the
> leading "/dev/tty" from the output of tty using a shell parameter
> expansion:
> 
>   ttyGetNum() {
>     local t
>     t=$(tty) || return 1
>     [[ $t = /dev/tty+([0-9]) ]] || return 1
>     r=${t#/dev/tty}
>   }
> 
>   if ttyGetNum; then export Xorg_vt=vt"$r"; fi
> 

fgconsole returns the current virtual terminal number.
chvt switches to a specified virtual terminal.

These are from package kbd.

-dsr-

[toc] | [prev] | [next] | [standalone]


#197399

FromZenaan Harkness <zenaan@freedbms.net>
Date2018-07-09 16:00 +0200
Message-ID<w9ERQ-2Em-1@gated-at.bofh.it>
In reply to#197398
On Mon, Jul 09, 2018 at 09:41:32AM -0400, Dan Ritter wrote:
> On Mon, Jul 09, 2018 at 09:08:17AM -0400, Greg Wooledge wrote:
> > On Sun, Jul 08, 2018 at 01:08:59PM +1000, Zenaan Harkness wrote:
> > > With a bash fn like:
> > >   ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }
> > > 
> > > Then something like this will id your current tty:
> > >   ttyGetNum;  export Xorg_vt=vt$?
> > 
> > Ewwwww!
> > 
> > The return status of a shell function is NOT intended to be used this way.
> > It's analogous to the exit status of a shell command.  It's a single
> > byte, unsigned, so you can only return 0 to 255.  It's intended to convey
> > success or failure, not to carry an actual data payload.
> > 
> > I recommend that you switch to using a regular variable for this purpose.
> > I happen to like "r".  With a regular variable, you're not restricted to
> > integers from 0 to 255, and you retain the ability to convey succss/failure
> > through the return code.
> > 
> > As an aside, you can save the call to GNU grep by simply stripping the
> > leading "/dev/tty" from the output of tty using a shell parameter
> > expansion:
> > 
> >   ttyGetNum() {
> >     local t
> >     t=$(tty) || return 1
> >     [[ $t = /dev/tty+([0-9]) ]] || return 1
> >     r=${t#/dev/tty}
> >   }
> > 
> >   if ttyGetNum; then export Xorg_vt=vt"$r"; fi
> > 
> 
> fgconsole returns the current virtual terminal number.
> chvt switches to a specified virtual terminal.

Sweet!

> These are from package kbd.

Was already installed by me :)

And this will satisfy Dan's objection to a perfectly good use of
"return" values ;D

[toc] | [prev] | [next] | [standalone]


#197400

FromZenaan Harkness <zenaan@freedbms.net>
Date2018-07-09 16:00 +0200
Message-ID<w9ERQ-2Em-9@gated-at.bofh.it>
In reply to#197399
On Mon, Jul 09, 2018 at 11:52:05PM +1000, Zenaan Harkness wrote:
> On Mon, Jul 09, 2018 at 09:41:32AM -0400, Dan Ritter wrote:
> > On Mon, Jul 09, 2018 at 09:08:17AM -0400, Greg Wooledge wrote:
> > > On Sun, Jul 08, 2018 at 01:08:59PM +1000, Zenaan Harkness wrote:
> > > > With a bash fn like:
> > > >   ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }
> > > > 
> > > > Then something like this will id your current tty:
> > > >   ttyGetNum;  export Xorg_vt=vt$?
> > > 
> > > Ewwwww!
> > > 
> > > The return status of a shell function is NOT intended to be used this way.
> > > It's analogous to the exit status of a shell command.  It's a single
> > > byte, unsigned, so you can only return 0 to 255.  It's intended to convey
> > > success or failure, not to carry an actual data payload.
> > > 
> > > I recommend that you switch to using a regular variable for this purpose.
> > > I happen to like "r".  With a regular variable, you're not restricted to
> > > integers from 0 to 255, and you retain the ability to convey succss/failure
> > > through the return code.
> > > 
> > > As an aside, you can save the call to GNU grep by simply stripping the
> > > leading "/dev/tty" from the output of tty using a shell parameter
> > > expansion:
> > > 
> > >   ttyGetNum() {
> > >     local t
> > >     t=$(tty) || return 1
> > >     [[ $t = /dev/tty+([0-9]) ]] || return 1
> > >     r=${t#/dev/tty}
> > >   }
> > > 
> > >   if ttyGetNum; then export Xorg_vt=vt"$r"; fi
> > > 
> > 
> > fgconsole returns the current virtual terminal number.
> > chvt switches to a specified virtual terminal.
> 
> Sweet!
> 
> > These are from package kbd.
> 
> Was already installed by me :)
> 
> And this will satisfy Dan's objection to a perfectly good use of
> "return" values ;D

s/Dan/Greg/ # I need sleep alert

[toc] | [prev] | [next] | [standalone]


#197401

FromZenaan Harkness <zenaan@freedbms.net>
Date2018-07-09 16:00 +0200
Message-ID<w9ERQ-2Em-11@gated-at.bofh.it>
In reply to#197392
On Mon, Jul 09, 2018 at 09:08:17AM -0400, Greg Wooledge wrote:
> On Sun, Jul 08, 2018 at 01:08:59PM +1000, Zenaan Harkness wrote:
> > With a bash fn like:
> >   ttyGetNum () { return $(tty | grep -oE '[0-9]+$') ; }
> > 
> > Then something like this will id your current tty:
> >   ttyGetNum;  export Xorg_vt=vt$?
> 
> Ewwwww!

:D


> The return status of a shell function is NOT intended to be used this way.
> It's analogous to the exit status of a shell command.  It's a single
> byte, unsigned, so you can only return 0 to 255.  It's intended to convey
> success or failure, not to carry an actual data payload.

It's a byte, and I have slightly less than 255 Linux VTs, so it's
adequate to this particular purpose ;)


> I recommend that you switch to using a regular variable for this purpose.
> I happen to like "r".  With a regular variable, you're not restricted to
> integers from 0 to 255, and you retain the ability to convey succss/failure
> through the return code.
> 
> As an aside, you can save the call to GNU grep by simply stripping the
> leading "/dev/tty" from the output of tty using a shell parameter
> expansion:
> 
>   ttyGetNum() {
>     local t
>     t=$(tty) || return 1
>     [[ $t = /dev/tty+([0-9]) ]] || return 1
>     r=${t#/dev/tty}
>   }
> 
>   if ttyGetNum; then export Xorg_vt=vt"$r"; fi

I have been on a bit of a "support dash/ posix shell" and therefore
removed various Bash-isms. There was at least one bash-ism (that I
was using) that I was not able to remove. At least not easily.

I don't remember what that was at the moment - haven't been hacking
on this for some months.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web