I've tried a bunch of commands but they all attach the session into the current session and they as you can imagine it bails when I try to reattach it later as it's already attached in the session nest.
I create sessions for each project I work on with windows to remote servers, logs and vim.
But everytime I want to switch I have to C-a d then screen -DR
I'd rather be able to just type a single command.
Thanks
AFAIK this is not possible with screen and I know of no way to easily work around this limitation. The issue here is that each screen session is independent and has no knowledge of other sessions.
If this is a feature you will use often, I would recommend switching to tmux which does this with <C-b>s. I've used both screen and tmux extensively and have not regretted favoring tmux this past year whenever a terminal multiplexer was called for.
On a side note running nested screen sessions is not too difficult, just send two escapes and commands go to the inner screen session, it helps if the escape is a single character, I like:
escape ``
Related
I have 2 monitors at work and 2 monitors at home.
When I log into work from home using mstsc /span, my work desktop appears correctly spread across my 2 home monitors.
Then I want to open another RDP session on my work machine. When I maximise that window, it now fills both of my home monitors. How can I make it just fill the monitor it is on - like it would if I was at work and NOT using mstsc /span?
The solution is to edit the file "default.rdp" created in your Documents forder.. You need to add a setting for "selectedmonitors:s:x,y,z,*".
If you want to know which number is your monitor, execute "mstsc /l" in ms-doc command.
As seen on
https://remotedesktop.uservoice.com/forums/266795-remote-desktop-services/suggestions/18010924-allow-ability-to-choose-subset-of-local-monitors-f
Scott Hanselman also answered inside a comment with his own blog. his solution is very detailed:
https://www.hanselman.com/blog/HowToRemoteDesktopFullscreenRDPWithJustSOMEOfYourMultipleMonitors.aspx
This is an old question but I'll suggest an answer now anyway in case someone lands up here.
It seems to me that to solve this problem there is no need for selectedmonitors in the RDP file. Instead of using /span to connect to work you should be using /multimon.
/span creates one big "screen" across your two home monitors. So when you go "fullscreen" in your work session it goes across them.
/multimon makes your work computer aware of your two-monitor setup. When you maximise a window or go full-screen it will do so in the way you'd expect.
As I have found recently, selectedmonitors could be useful if your primary monitor at home is not the one which you want to consider the primary in your work session.
In the answer to this post Corey Henderson explains how you can use the at and stuff commands in screen to send commands to all windows of a screen session at once. I would like to know how I can stuff the input buffers to some windows at the same time. In other words, I would like to use a filter to specify which windows should receive the input and which should not.
It would be great if I could filter on the window number instead of the user name or the window name because bash likes to change the window name sometimes and it is inconvenient to modify the .bashrc on multiple machines. Also, sometimes I don't have control over which user I am running the command as.
So far I have only been able to run a command on either the currently active window or all windows at once.
The only way I have found to do windows filtering when using the atcommand is by using windows names.
By default screen's windows names are set after the actual command name of the program created in the window, for me this is usually bash. But windows names can be changed to whatever you prefer with Ctrl+A. If your windows' names change dynamically, check you don't have Dynamic Titles enabled.
So in practice that means you can give related windows a common prefix and then use at "prefix#" stuff "command" to execute the command only on those windows whose names matches the filter.
Imagine we have the following windows opened in our screen session:
0$ front1 - 1$ front2 - 2$ back1 - 3$ back2 - 4$ back3 - 5$ db1 - 6$ db2
The next command would send the service ntpd stop command to windows starting by the string back, that is back1, back2, back3:
at "back#" stuff "service ntpd stop^M"
I have a VB application which is scheduled. It focuses on some cmd windows and performs sendkey actions. This works fine when I have the RDP session open, it's only when I disconnect (not logoff) that the issue occurs. (This task is running on a virtualised server).
When I open the RDP session again after the task has ran, the application has thrown an error regarding the login permissions. I presume this is because the user is locked and therefore can't perform the actions?
I need to find a way around this, any help is much appreciated!
Don't use SendKeys.
Instead, if you have a program running in a command prompt, make sure the VB.NET program is the one to open it (or them) with Process.Start, and set the RedirectStandardInput property of the ProcessStartInfo object you pass to True. Then pass commands into the process's StandardInput property as though writing to a file.
This will avoid any focus-change problems, any problems to do with locked screen sessions, most if not all potential problems with integrity levels, most if not all problems with timing, and probably some other stuff I'm not thinking of.
I'm writing a WLST script to deploy some WAR's and an EAR. However, intermittently, the script will time out because it can't seem to get an edit lock (this script is part of a chain of many other scripts). I was wondering, is there a way to override or stop any current locks on the server? This is only a temporary solution, but in the interest of time, it will do for now.
Thanks.
You could try setting a wait period and timeout:
startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).
Are other scripts erroring out, leaving the session locked? You could try adding exception handling around those. Also, if you have 'Automatically acquire lock" enabled in the Admin Console and you use the admin console sometimes it can cause problems if you are running scripts at the same time, even though you are not making "lock-requiring" changes.
Also, are you using the same user for the chained scripts?
Within WLST, you can pass a number as a parameter to gain an exclusive lock. This allows the script to grab a different lock than the regular one that's used whenever an administrator locks from the console. It also prevents two instances of the same script from stepping on each other.
However, this creates complex change merge scenarios that are best avoided (by processes).
Oracle's documentation on configuration locks can be found here.
Alternatively, if you want the script to temporarily relieve any existing locks regardless of the pending changes, you may as well disable change management from the console, minimizing the inconvenience caused.
WLST also contains the cancelEdit command that you could run before you startEdit. Hope one of these options pan out!
To take the configuration change lock from another administrator:
If another administrator already has the configuration lock, the following message appears: Another user already owns the lock. You will need to either wait for the lock to be released, or take the lock.
Locate the Change Center in the upper left corner of the
Administration Console.
Click Take Lock & Edit.
Make your configuration changes.
In the Change Center, click Activate Changes. Not all changes take
effect immediately. Some require a restart (see Use the Change
Center).
As long as you're running WLST as an administrative user, you should be able to jump into an existing edit session with the edit() command - I've done a quick test with two admin users, one in the Admin Console, and one using WLST, and it appears to work fine - I can see the changes in the Admin Console session inside the WLST interpreter.
You could put a very simple exception handler around your calls to startEdit that will log the exception's stack trace, but do nothing else. And then rely on the edit call to pop you into the change session.
Relying on that is going to be tricky though if another script has started an edit session and is expecting to be able to commit that change session itself - you'll be getting exceptions and unreliable behaviour across multiple invocations.
Every morning when I get into work I launch about a dozen apps and whatnot (FF, TB, VSx2-3, Eclipse, SSH, SVN update x2-3). Needles to say this does a good job of warming up my HDD for the day. I rather suspect that it would run a lot faster if they were launched sequentially (not to mention that I wouldn't need to click in 17 different places).
Is there a preexisting product that can kick off a sequence of tasks/apps/etc. where each task is only started after the last app is done hammering the HDD?
It would nerd to be able to kick apps like VS and firefox and also be able to trigger explorer context menu items like SVN update in TortoiseSVN.
Try SlickRun, it's free, I've used it for years, I use it constantly and I'd be lost without it.
Think of it like a configurable Start->Run command, it'll do what you want (you can configure n second pauses between multiple commands), and if you install it you'll use it for a thousand different things before the first week is out.
P.S. I have no stake in SlickRun, I just like it :)
Unfortunately, I don't know of any software that can do this for you automatically.
However, can't you trigger the updates through a console SVN task? If so, can't this be done by creating a batch file? It's low tech, and you might want to add a few pauses between each task, but it should do what you want.
As you mention TortoiseSVN, I'll assume your O/S is windows.
You could launch an Autohotkey script at startup. I don't think it can easily detect HDD activity, but you can at least wait until each window appears with the WinWaitActive command.
If each application has an average time they take to complete, you could simply use Windows' Scheduled Tasks application. Obviously you'll need to be running Windows but Scheduled Tasks can be found in the Control Panel.
Execute "Add Schedules Task", select the program, the frequency and then the specific time.