Mimic multiple linux terminals.

[dante65]

I am in first hand not asking here how to do what i want, but it could be nice to get some different views about which could be the best solution.

My question is quite simple, but i having a hard time put this right in proper english, so there is a chance that i got misunderstood here-and my fear for that probably make my question more lengthy than it otherwise would be.

My goal is to add a “linux-terminal” style to my fvwm-setup.
I want to have 6 logins by using the xterm or another good terminal emulator.
I am going to switch between them with the alt-F1 to alt-F6 keys, but i am not going to get down into any real linux-terminal with, for example ctrl-alt-F6 - and i want them to get up in full screen without any borders, and i don’t want to see any icons or windows belonging to them when not using them.
I am planning to use different screen-session thats automatically is started up in each of them.

As i can see there is a few ways to accomplish this.

Alternative 1 could be to get an xterm on a desktop thats not seen in my fvwm-pager (for the moment i have 9 desktops in the pager)), so maybe i i should get them up in fixed pages on at page 1 to 6 on the desk number 10 and let the alt-Fx keys switch between each page on that desk.

Alternative 2 could be that i only use one xterm and using the alt-Fx keys to performe fvwm to call screen for attach/deattach between screen sessions, and in that case i should use the setting be that when i am not in any of them - the screen session will be deatached and the xterm is closed.

I also have been thinking about the alternative to switch between screen-sessions in xterm and somehow attach/deattach different screen-sessions within the xterm (that maybe could be accomplished by spawning sub-sessions of screen inside screen itself and bind the alt-Fx keys to switch between these sub-sessions.?) . But this solution, whatever is possible or not - is not what i want in first case because i want the whole setup to be bind to Fvwm for portability issues.

Any ideas which solution should be the best - ideas about other alternatives.?

And again - i am sorry for this posting being so lengthy
/Dante65

[thomasadam]

@dante65

i want them to get up in full screen without any borders, and i don’t want to see any icons or windows belonging to them when not using them.

Well, the first part is easy:

Style whatever HintOverride, !Title, !Borders, BorderWidth 0, HandleWidth 0

Then set them to be maximized when they’re started:

DestroyModuleConfig FE-sw:*
*FE-sw: add_window SomeFunc

DestroyFunc SomeFunc
AddToFunc   SomeFunc
+ I ThisWindow ("name1|name2|name3|name4|etc", !Maximized, Maximizable) Maximize

AddToFunc StartFunction I Module FvwmEvent FE-sw

As for when you’re “not using them”, you’ll need to explain the circumstances for that.

– Thomas Adam

[dante65]

I will test the code, thanks.

As for when you’re “not using them”, you’ll need to explain the circumstances for that.

I mean - when i do something else than being in any of my pseudo-terminals, then i want them to be completely hidden, as if i had pressed ctrl-alt-F5 (for example), to be in the terminal-mode - and then alt-F7 to go back to X (yes - Fvwm, )

I want to keep the feeling but replace the linux-terminals with xterm/xterms.
The reason to doing so is that some programs (vim,emacs) which i prefer to run in terminal-mode, have some ‘features’ that can’t be used in the real linux.terminal, for example - afaik, mappings to the shit-key and for faster speed when i switch back and forth to X.

To get the feeling as close as possible i will use alt-F7 to switch back to the program i was using before i was going in ‘pseudo-terninal’-mode.

I think i will call them pseudo-terminals from now on - if thats not completely erroneous.

/Dante65

[dante65]

Correction

when i do something else than being in any of my pseudo-terminals, then i want them to be completely hidden,

Should be - completely hidden or closed - depending on what is the most efficient way doing it, but i want all to be ‘restored’ when i press alt-Fx again, exactly as if i was switching back and forth between X and linux-terminals.

Thomas - maybe i didn’t i understand what you was asking me about.? :-/

/Dante65.

[thomasadam]

@dante65

Should be - completely hidden or closed - depending on what is the most efficient way doing it, but i want all to be ‘restored’ when i press alt-Fx again, exactly as if i was switching back and forth between X and linux-terminals.

So have it iconified with no icon, and set WindowListSkip, or perhaps shade the window?

– Thomas Adam

[dante65]

Now i have this in my config …just as a simple test for later improvement.
pTTY here is just my naming for pseudoTTY, yes i know that it’s not complete right to name it so .- but i will stick to that until i got a better name.

Key F1 A M Func_xterm-pTTY 1 screen-config_FVWM Key F2 A M Func_xterm-pTTY 2 screen-config_EMACS Key F3 A M Func_xterm-pTTY 3 screen-config_VIM
Where screen-xxx is a script which start/(re)attach a session of screen with a few programs running.

[code]
DestroyFunc Func_xterm-pTTY
AddToFunc Func_xterm-pTTY

• I Func_deattach-screen_n_close " this function doesn’t exist yet
• I Style “xterm-pTTY_*” !Title, !Borders, BorderWidth 0, HandleWidth 0
• I Exec exec xterm -name xterm-pTTY_$0 -geometry 170x59+0+0 -e $1
  " (ik, i should let fvwm set the size, i do it later)[/code]

I want any call to Func_xterm-pTTY to deattach the session of screen running within any of the xtems that earlier was opened within that function.
Is it possible.?

Alternately i could open a separate xterm for each of them and then reassign the key (via piperead .?) to send me to that desk and page where i have placeed the xterm…? But then again - is it possible to deattach screen and close xtermt, is there a ‘automatic’ way to go.?

Also - i want the xterm(s) opened from that function to deattach any session of screen and be completely closed when i press alt-F7. (which should let me jump back to the deska and page i was on before i did a call to Func_xterm-pTTY.

Is it possible.?
Is there a simpler/better/more clever way.?

/Dante65

[thomasadam]

@dante65

• I Style “xterm-pTTY_*” !Title, !Borders, BorderWidth 0, HandleWidth 0

This doesn’t need to be in a function – just place it with the rest of your Styles.

@dante65

I want any call to Func_xterm-pTTY to deattach the session of screen running within any of the xtems that earlier was opened within that function.
Is it possible.?

Assuming you use FvwmCommandS in your StartFunction then you can do something like:

screen -RDS foo foo && FvwmCommand 'SomeCommandOrFunction'

– Thomas Adam

[dante65]

This doesn’t need to be in a function – just place it with the rest of your Styles.

Ahh -yes ty.

Assuming you use FvwmCommandS in your StartFunction then you can do something like:

screen -RDS foo foo && FvwmCommand 'SomeCommandOrFunction'

Ok - i invoke it, on top of my .fvwm2rc

AddToFunc StartFunction I Module FvwmCommands

I have spent quite some time to understand where fwmcommands come in place, and if i don’t missunderstood you - then you suggest me to open screen in xterm - and appropriately do a call to fvwmcommands from that shell which willl execute when screen is detached or closed .?
I am quite unsure how to use the &&, and i don’t understand what i could put into fvwmcommand.

I have googled for fvwmcommand|fvwmcommands … and what i have find doen not make it much easier to me to understand.

I have made the decision that i want each pTTY to be closed when spawning a new one.
This is what i have performed so far…

[code]
Key F6 A M Func_xterm-pTTY 6 std_FVWM
Key F5 A M Func_xterm-pTTY 5 std_EMACS
Key F4 A M Func_xterm-pTTY 4 std_VIM

DestroyFunc Func_xterm-pTTY
AddToFunc Func_xterm-pTTY

• I Exec exec xterm -e screen-detach-std
• I Exec exec xterm -name xterm-pTTY_$0 -geometry 170x59+0+0 -e screen-$1[/code]The script screen-detach-std simply checks if any of my screen-std_XXX sessions is attached, if so . then it detach it.

This works pretty well - if i press altl-F4 i jump into the screen session std_VIM, and if i press alt-F6 i detach the current screen session and jump into std_FVWM.

However, i can’t manage to get them all detached so i return to whats “behind” the xterm…
I have tried the following…

[code]
Key F7 A M Func_Detach-std

DestroyFunc Func_Detach-std
AddToFunc Func_Detach-std

• I Exec exec xterm -e screen-detach-std
  [/code]…Which doesn’t work.
  But it works if i jump into term and run the script from there. And it work when i run it as the first line in Func_xterm-pTTY

Also i think that the use xerm,to run the script is overkill…?

Here is the important parts of my scripts…

[code]
#screen-std_FVWM
#!/bin/bash

if screen -ls | grep std_FVWM | grep Attached
then

echo Attatched, Detaching

echo and then Attach again

sleep 5

    screen -d -S std_FVWM
    screen -r -S std_FVWM

#Strange enough i cant get screeen -DR to work as expected when running from thsi script.
elif screen -ls | grep FVWM | grep Detached
then

echo Detached - Reattaching

sleep 5

    screen -r -S std_FVWM

else

echo No Screen Session - Creating std_FVWM

sleep 5

    cd ~/.fvwm
    screen -d  -m  -S std_FVWM

    screen -X -S  std_FVWM screen -t emacs-fvwm2rc 1
    screen -X -S  std_FVWM -p 1 stuff "emacs -nw ./.fvwm2rc
    "

->.some other stuff snipped out<-
screen -x std_FVWM -p 3
fi[/code]

[code]
#screen-detach-std
if screen -ls | grep Attached | grep std_FVWM
then screen -d -S std_FVWM
fi
if screen -ls | grep Attached | grep std_VIM
then screen -d -S std_VIM
fi
if screen -ls | grep Attached | grep std_EMACS
then screen -d -S std_EMACS
fi

It could be more effective,using strings and so on - well, later on.[/code]

/Dante65

[thomasadam]

@dante65

AddToFunc StartFunction I Module FvwmCommands

No – I said “FvwmCommandS” and meant it – it’s case sensitive, so unless what you have written there is a typo, nothing from FvwmCommand will work, as the “FvwmCommandS” function sets up a FIFO which the command FvwmCommand sends its data down back to FVWM.

@dante65

I have spent quite some time to understand where fwmcommands come in place, and if i don’t missunderstood you - then you suggest me to open screen in xterm - and appropriately do a call to fvwmcommands from that shell which willl execute when screen is detached or closed .?

Yes, that’s right. “FvwmCommand” is nothing more than a way to send FVWM-specific commands from external programs which aren’t FVWM-related – so specifically from shell scripts, etc. In your case, you want a way to tell FVWM to issue a command (whatever that might be – I’ve forgotten but I am sure you can remember now) when screen is detached. The snippet of code I gave you ensures that.

@dante65

I am quite unsure how to use the &&, and i don’t understand what i could put into fvwmcommand.

It’s easy. The line such as:

Exec exec xterm -T SomeName -e screen -RDS somename someinitialcommand && FvwmCommand 'Next (SomeName) Iconify

(I’m assuming the above is issued in FVWM – perhaps as part of a menu entry or a keybinding) means that xterm is started with a title of SomeName and immediately is told to execute screen. Assuming that was successful (which is what “&&” means in bash), then the FvwmCommand runs, telling FVWM to iconify the window SomeName. This works, because detaching the sceen process returns true.

@dante65

I have googled for fvwmcommand|fvwmcommands … and what i have find doen not make it much easier to me to understand.

See above.

@dante65

I have made the decision that i want each pTTY to be closed when spawning a new one.

Err, why such a complicated (and I am afraid to say broken) script, when:

screen -RDS somesessionname

– Thomas Adam

[dante65]

No – I said “FvwmCommandS” and meant it – it’s case sensitive, so unless what you have written there is a typo, nothing from FvwmCommand will work, as the “FvwmCommandS” function sets up a FIFO which the command FvwmCommand sends its data down back to FVWM.

Yes it was a typo - in my .fvwm2rc, ty.

…In your case, you want a way to tell FVWM to issue a command (whatever that might be – I’ve forgotten but I am sure you can remember now) when screen is detached. The snippet of code I gave you ensures that.

Thanyou for the snippet - but it was not really what i was asking for in first place.
Quoting myself here.

I want any call to Func_xterm-pTTY to deattach the session of screen running within any of the xtems that earlier was opened within that function.
Is it possible.?

What i meant, and please before flame, remember that i am not very good expressing myself in english - i want all instance of screen which begins std_ to be closed, so i only have the newest session of std_ running at the same time.
To perform this i created the script screen-detach-std

Err, why such a complicated (and I am afraid to say broken) script, when:

screen -RDS somesessionname

What i need is to attach to a named scren-session if it’s running.
If it’s not running- create my desired session with some default apps and names to the windows.
For that i need screen to start in detached mode (screen -d -m)
So i need at least one if else, statement.
I heve shortened the if-stetement.

[code]if screen -ls | grep std_FVWM
then
screen -D -R -S std_FVWM #attaching session
else
cd ~/.fvwm
#creating session in detached mode
screen -d -m -S std_FVWM
#creating and naming window 1 in screen
screen -X -S std_FVWM screen -t emacs-fvwm2rc 1
#telling screen to perform command.when attached
#the linefeed makes the string sent to command-line in screen to be performed as a command
screen -X -S std_FVWM -p 1 stuff "emacs -nw ./.fvwm2rc
"
… some other commands

   screen -R  std_FVWM -p 3

fi[/code]
where is it broken.?
Could i realy do it shorter - less complicated.?

My problem for now is - why is the call to screen-detach-std lost when i run it from a function in fvwm, but not when it is on the first line of another function.?

If i solve that- then i can get back to the running x-app if i press alt-F7.

/Dante65

[thomasadam]

@dante65

What i need is to attach to a named scren-session if it’s running.
If it’s not running- create my desired session with some default apps and names to the windows.
For that i need screen to start in detached mode (screen -d -m)

No – you really do want:

screen -RDS somename -c some_screen_config_file

Now, guess what this does. This will create or attach where necessary the desired screen sessions, using a named config file. If you happen to invoke it as:

Exec exec xterm -T foo -e screen -RDS ....

Then binding that to the commands which launch these ““VTs”” of yours have the added advantage of opening and/or closing where necessary – this includes power detaching of the screen session.

– Thomas Adam

[dante65]

No – you really do want:

: screen -RDS somename -c some_screen_config_file

Now, guess what this does. This will create or attach where necessary the desired screen sessions, using a named config file. If you happen to invoke it as:

Yes - thats [size=125]exactly[/size] what i want, [size=125]If[/size] there is a way exit the program in the named window and return to bash instead of get the window closed when the program is closed.

Thats possibly - AFAIK only if you invoke screen from command line or from shellscript… But i can be wrong there.

If its not possible, then i still want to use my scripts - and learn to know how, if possible, to track the error i mentioned before.

/Dante65

[thomasadam]

@dante65

Yes - thats [size=125]exactly[/size] what i want, [size=125]If[/size] there is a way exit the program in the named window and return to bash instead of get the window closed when the program is closed.

I love how, as more of these problems are solved, your requirements and reasons for needing these things change with them – it’s a bit like a crossword – I have vague clues, but nothing concrete.

You can fudge the effect in your screenrc file:

screen -t somecoolapp zsh -c 'zsh -c mycoolapp && zsh'

Certainly not ideal, but it will work. Note that “zsh” is the shell I would use, you probably want “sh” there.

@dante65

Thats possibly - AFAIK only if you invoke screen from command line or from shellscript… But i can be wrong there.

You are wrong. See above.

@dante65

If its not possible, then i still want to use my scripts - and learn to know how, if possible, to track the error i mentioned before.

But your scripts suck – the functionality you want is already in screen.

– Thomas Adam

[dante65]

Sorry for late response, i have been forced (by work) to use looseXP for a while
But now i am back in Linux again, and my dear fvwm

You can fudge the effect in your screenrc file]
screen -t somecoolapp zsh -c ‘zsh -c mycoolapp && zsh’
[/code]

first try

screen -t 'emacs -nw'  bash  -c 'bash -c emacs -nw && bash'

Which results in a screen session starting two instances of emacs within X (ignoring the -nw switch).

this is how my screenlist looks

Num Name Flags

0 emacs -nw $
1 emacs -nw $

here i test three windows.

screen -t jed 1 bash -c 'bash -c jed && bash' screen -t vim 2 bash -c 'bash -c vim && bash' screen -t nano 3 bash -c 'bash -c nano && bash'

which gives the following screenlist

Num Name Flags

1 jed $
2 vim $
3 nano $
4 jed $
5 vim $
6 nano $

/Dante65

[dante65]

My last problem was that i had double instances of each program running.

I did the mistake to source my $HOME/.screenrc twice - therefore the double instances of each program.

Thank you for your all help Tomas Adam, i think now i am ready to set up my config of pTTY’s.

/Dante65

[thomasadam]

@dante65

My last problem was that i had double instances of each program running.

I did the mistake to source my $HOME/.screenrc twice - therefore the double instances of each program.

Thank you for your all help Tomas Adam, i think now i am ready to set up my config of pTTY’s.

/Dante65

Most people get around this, by having their actual screen instances in ~/.screenrc (i,.e., those programs which start up automatically) in a separate file.

My name, by the way, has a “h” in it, even though it’s silent.

– Thomas Adam

[dante65]

I

Most people get around this, by having their actual screen instances in ~/.screenrc (i,.e., those programs which start up automatically) in a separate file

Actually I think that it should be the same problem anyway, because i did the (newbie) error to put source $HOME~/.screenrc in the global /etc/screenrc file.

My name, by the way, has a “h” in it, even though it’s silent.

I know. It was a typo from my side, sorry.

/Dante65

[dante65]

Actually I think that it should be the same problem anyway, because i did the (newbie) error to put source $HOME~/.screenrc in the global /etc/screenrc file.

Ahh -now i get your point, if i called the local specially-named screenrc-file from when inwoking screen, then i shouldn’t get that error - yes thats so right.

Becouse my use of screen has stalled for a while until i get this things to work, then my thinking was that it should be simpler to use only one simple ~/.screenrc configured for these testin0g-purposes ,

Anyway- i suppose it was good that i did it that way this time -otherwise i shouldn’t have seen the error that i invoked my ~/.screenrc file twice until i come into other - maybe less easy-solved problems.

/Dante65

[thomasadam]

@dante65

Ahh -now i get your point, if i called the local specially-named screenrc-file from when inwoking screen, then i shouldn’t get that error - yes thats so right.

Precisely.

– Thomas Adam

[dante65]

I still have one problem.
When i invoke screen (i still use my ~/.screenrc until i got it all to work) then i can’t get parameters to work.

ie screen -t vim-fvwm2rc 1 bash -c 'bash -c vim ~/.fvwm/.fvwm2rc && bash' starts vim , but does not fire up the file. And i know for sure that i got the file in that location- it fires up when i just type vim ~/.fvwm/.fvwm2rc on the commandline.

i have tested to set quotes and double-quotes around vim ~/.fvwm/.fvwm2rc , without any result.

/Dante65