I have a few windows in a single screen session and then I want to detach my session. There is no problem with that.
But I can't find a way to restore all windows within my previously detached session. I can see that I can restore just one of them by ID.
But how can I reattach exact the same session environment with all the windows in it?
--
Updated:
If I type screen -d -r, this is what is says:
There are several suitable screens on:
21074.pts-7.atx (05/29/2010 02:26:32 PM) (Attached)
3420.pts-3.atx (05/29/2010 12:16:41 AM) (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
How can I reattach all of them?
screen -d -r : Reattach a session and if necessary detach it first.
This will reattach your old session, will all its windows. If your session is still attached, it will detach it before attaching it to the current terminal. This is quite useful when for example you have kept your screen session in an ssh terminal on another computer.
To reattach all previously detached sessions I use this little script.
#!/bin/sh
for line in `screen -ls | grep Detached | awk '{print $1}'`; do
xdotool key control+shift+t type "screen -r $line"
xdotool key KP_Enter
done
"control+shift+t" happened to be a shortcut in my terminal for opening a new tab and it may be different shortcut in yours.
Related
I am using versions:
ESXI 6.5.0 Update 3 (Build 14990892)
Power CLI VMware PowerCLI 11.0.0 build 10380590.
I have a VM that I am importing (ISO) into an ESXI and trying to set Autostart on the VM to "enabled" programmatically via some scripts, but it is not working. I am using the powercli command:
Set-VMHostStartPolicy (Get-VMHost | Get-VMHostStartPolicy) -Enabled:$true
I've also tried some variants of this command but none seem to work. I see the "event" get logged as "Reconfigure Autostart" under the "Recent Tasks" menu on the ESXI Web GUI as soon as I input the command, so its definitely configurating something, but when I double-check the state of the VM to see if Autostart is enabled, it still lists "Enable" as an option, implying Autostart is NOT enabled. Here's a screenshot:
Can anyone help me please? I just want to have this VM start automatically incase there is a power outage or server crash; But only in these cases, I want it to import powered OFF for the first time (as you can see in screen shot the EPS VM is imported but in a powered down state, which is what I want)
I think what you're doing is setting the host's default policy... You would think that would work. I'm using this code on ESXi 7.0 Update 1 to set the guest's policy:
$vmstartpolicy = Get-VM "$vm_name" | Get-VMStartPolicy
Set-VMStartPolicy -StartPolicy $vmstartpolicy -StartAction PowerOn
It has the same issue that it doesn't show in the web UI, (which somebody will complain about, and I'll have to fix) but it does auto-start the VM after a reboot, so at least it's a start (pun not intended).
Edit: After playing around a bit, I managed to find a solution that updates the UI.
plink -batch -ssh $user#$IP -l "$user" -pw "$password" vim-cmd hostsvc/autostartmanager/update_autostartentry "`$(vim-cmd vmsvc/getallvms | grep `"$vm_name`" | awk '{print `$1}')" "PowerOn" 0 1 "systemDefault" "systemDefault" "systemDefault"
Using plink to ssh into the host and run this vim-cmd, it updates the UI properly. Take note of the back-ticks (`) to escape the dollar signs (except the one with the $vm_name variable) and quotes in the sub command, so that powershell doesn't try to interpret them before sending them through the ssh tunnel. All the sub command does is get the all the VMs, use grep to filter down to the output line with the vm_name you specify, and use awk to print only the 1st column (the vm id required for the outer vim-cmd).
I have found a similar question here but without a working answer for me:
System Clipboard Vim within TMUX within SSH session
I'm using Gnome terminal to start a ssh session with X forwarding to Debian 10.
If I start neovim and copy (yank) text, then this text is copied to the Gnome clipboard and everything is fine.
This is the content of .ssh/config :
Host nuc
ForwardX11 yes
I have this in .vimrc:
set clipboard^=unnamed,unnamedplus
But when I start neovim inside tmux, then this doesn't work.
I have tmux with the tmux-yank plugin and this works because when I copy from neovim inside tmux and then exit tmux I can see the selected text with xsel -o
How can I get the selection forwarded to my system clipboard?
Vim and NeoVim support for clipboard use a connection to the X11 server. The address to connect is available from the $DISPLAY environment variable.
The issue with X11 and terminal multiplexers or session managers such as tmux or screen is that the environment of the shells and programs running inside them will be the environment of when the tmux session was first created. That includes the $DISPLAY variable. So it means vim inside tmux will be trying to use the address of the X11 server of when the tmux session was created, not the one from where you just connected now.
A dirty but simple workaround is to update the $DISPLAY variable when you reconnect to tmux, to ensure you'll be connecting to the correct X11 server. Note that you need to do that for every shell or program running inside tmux, since each of them will have its own out-of-sync copy of the environment variable.
Something like the following works:
$ ssh -X nuc
nuc$ echo $DISPLAY
:1234.1
nuc$ tmux attach
tmux$ export DISPLAY=:1234.1
tmux$ vim
This should make clipboard work for that particular Vim.
As mentioned, if you have many tmux windows and panes, you'd have to update $DISPLAY on all of them. Also, if you create new windows or panes, they will start with the wrong $DISPLAY setting too (though you can also update the value of $DISPLAY in tmux's environment to fix new windows and panes, see tmux's set-environment command for that.)
I use tmux 1.6-2 on a Debian 7.6 (wheezy).
I open a new session and start a long running script that gives updates in form of a progress bar and an activity indicator (spinning bar: /-\|/ ).
When I detach and reattach everything is still fine. But after some random time when I reattach the screen content is stuck. No spinning bar, no progress. I looked into the following:
I can see in top that the process is still running
I can successfully enter tmux commands (like new window, detach, etc.)
I can kill the script with Ctrl-C, but the tmux screen doesn't change
Ctrl-S and Ctrl-Q (like suggested in other threads) doesn't help
Any help is very much appreciated.
I managed to unfreeze my tmux session by running choose-client command from tmux's command line <prefix> :
where prefix is C-b by default
I found the solution in the bug report (by Taisuke Yamada).
I am using ConEmu and am totally satisfied with it except for the fact that if I use PuTTY for SSH access, I can then run commands on the remote machine like vim or nano or mcedit or others which opens some kind of a curses-interface and I can see the console commands history, but when I use CygWin SSH client or OpenSSH for Windows I cannot see the commands history anymore after running vim/nano/mcedit/whatever else.
When I quit those programs (:wq in vim, Esc key in mcedit, Ctrl^X in nano) I can see all the previous commands executed, like this (if I use PuTTY):
Run PuTTY and connect to some host
You will see something like that in history:
host$ whoami
user
host$ vim
...do something in vim then press :wq
And you should see exactly this:
=== Cut ===
host$ whoami
user
host$ vim
host$
=== Cut ===
all the previous commands (whoami) are visible. However if I run ConEmu and then use SSH client from CygWin (or OpenSSH client, it doesn't matter) the following happens:
Run ConEmu
ssh user#somehost
host$ whoami
user
host$ vim
...do something in vim then press :wq
And now the screen is empty! No history! You just see this:
=== Cut ===
host$
=== Cut ===
As if no whoami was executed. Same happens for mcedit, nano or any other programs that has something like a "screen". Also same happens with Ctrl-O in Midnight Commander, in PuTTY everything is nice, but when using ssh from CygWin in ConEmu (or OpenSSH Windows client) and running Midnight Commander each Ctrl-O just shows an empty history. As if nothing was typed previously. That is really not nice at all.
Is there any way to fix that?
The standard TERM environment variable for PuTTY.exe is xterm and that will mostly work for Cygwin ssh.exe as well. However, a better TERM environment variable for ssh.exe is cygwin.
When you use Cygwin ssh.exe to connect to another system, Cygwin processes your escape sequences, not ConEmu. In fact you get the same behavior whether you are running ssh.exe inside or outside of ConEmu. So the problem is not really related to ConEmu at all, at least not its ANSI processor.
The solution is to use the cygwin for the TERM environment variable on the remote system. In fact, the SSH client and server cooperate to do this for you automatically. But perhaps you have accidentally overridden the supplied TERM variable with say xterm in your .bash_profile or whatever. In that case, the escape sequence to restore the screen buffer after exiting the editor won't be correct for the Cygwin ANSI processor.
You can do this test to check whether this solves your problem:
$ export TERM=xterm
$ vim
$ # the screen before is cleared
$ export TERM=cygwin
$ vim
$ # the screen buffer is restored
My .screenrc has some initialization code that opens some windows. It's neat.
What I want to do, while running screen is simply , with one command open a new screen window that is running a program.
It SHOULD be:
screen -t 'CADMIN' sudo cherokee-admin -b
This actually works, except that it also runs my .screenrc and opens up all of my
windows in a nested screen. FAIL.
I know I could use
^c ( to create a new window )
^cA ( to title it )
sudo cherokee-admin -b
and get the same effect, but I'd like to bring a little elegance to my life, which
is why I use screen and not some multi terminal thing.
Ideas?
Ok, I've got a somewhat palatable answer:
from the bugs page there is a discussion about problems using the screen -t invocation.
I've tried this and I find that screen -c /dev/null -t CADMIN sudo cherokee-admin -b actually works the way I originally thought it would. It's kind of nifty actually, -c calls nothing for the value of .screenrc, which does not open my glorious screen rig. I can live with this.
You could setup another .screenrc file that doesn't have all of the other windows in it then in your .bash_profile you could add something like:
alias scn="screen -c '.screenrc2' -t 'CADMIN' sudo cherokee-admin -b"
then all you would have to do is run $scn from the cli to open screen with the desired effect.
hope this helps
edit: Make sure you name the second .screenrc file something different (i.e. '.screenrc2')