Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #197327 > unrolled thread
| Started by | Carl Fink <carlf@panix.com> |
|---|---|
| First post | 2018-07-07 22:40 +0200 |
| Last post | 2018-07-09 16:00 +0200 |
| Articles | 7 — 4 participants |
Back to article view | Back to linux.debian.user
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
| From | Carl Fink <carlf@panix.com> |
|---|---|
| Date | 2018-07-07 22:40 +0200 |
| Subject | VT2 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]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2018-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]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2018-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]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2018-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]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2018-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]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2018-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]
| From | Zenaan Harkness <zenaan@freedbms.net> |
|---|---|
| Date | 2018-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