Working in low bandwidth environments sometimes I need to share a text console (TTY) screen with a co-worker. I often use the screen(1) tool to keep multiple windows open in the same SSH connection and be able to reconnect and continue where I left off, when my connections drop due to bad internet. I wonder if we could not attach multiple SSH sessions / TTYs to the same screen(1) session so that my co-worker(s) and I can both use the same console? It should be possible, but is it?
The answer is as follows:
first screen session is started with
screen ...
then from another console as the same user someone else can attach to the same screen session with
screen -x
And then they can both work, one thing typed by one will be visible by both, etc.
Note: if the screen session has multiple windows, then each attached terminal can switch to a different window independently.
Related
I have a process that runs as root in the background. When a certain even occurs, I have it pop up an NSAlert with an NSTextField on it so the user can provide some info. However, the user is unable to click on the TextField or type anything into it. I can drag the Alert box around and click on the buttons on the Alert just fine.
I'm guessing this is because my process is running as root and not the end user account that is logged into the machine. Is there a way to easily get around this without spawning a separate process as the user and piping back the info via Distributed Objects or the like?
The best thing to do is to have your UI stuff running as the current user, not only because of problems like this, but also because running a GUI app as root poses a large number of security risks, and in fact there have been a number of security vulnerabilities in the past which were caused by some AppKit-enabled process running as root.
With that said, XPC is the mechanism you want to use to communicate between the root tool and the GUI app, not Distributed Objects, which is quite antiquated and has a number of issues of its own.
I'm working on a large scale music app and I'm having trouble with some nodes not connecting and disconnecting properly.
Is there a method in web audio to see a list of current connections a AudioNode has?
I've tried using Firefox's Developer browser as this shows a view of all current connections but the problem is that it's viewer really can't handle more than about 15 connections.
It would be great if there was something like: osc.connections(); which would return an array of nodes the osc is connected to.
If the Firefox tools doesn't do the trick, then I think the answer is no. I think I saw a Chrome extension which did something similar way back, but I can't find any trace of it.
Your best option is probably to keep track of the connections yourself, unfortunately.
So I have been trying to find some sort of information on how GNU screen actually works at a high without actually having to read through the source code but I have been unable to do so.
What does screen do that it is able to stick around even when a terminal session is closed? Does it run as a daemon or something and everyone who invokes screen just connects to it and then it finds which pseudo tty session to attach to or does it do something completely different?
There's a lot of potential questions in this question, so I'm going to concentrate on just one:
What does screen do that it is able to stick around even when a terminal session is closed?
Screen catches HUP signals, so it doesn't automatically exit when its controlling terminal goes away. Instead, when it gets a HUP, it goes into background mode (since it no longer has an actual terminal attached) and waits. When you start screen with various -d/-D/-r/-R/-RR options, it looks for an already running screen process (possibly detached after having received a HUP, and/or possibly detaching it directly by sending it a HUP) and takes over the child terminal sessions of that screen process (a cooperative process whereby the old screen process sends all the master PTYs to the new process for it to manage, before exiting).
I haven't studied Screen itself in depth, but I wrote a program that was inspired by it on the user end and I can describe how mine works:
The project is my terminal emulator which has an emulation core, a gui front end, a terminal front end, and the two screen-like components: attach.d and detachable.d.
https://github.com/adamdruppe/terminal-emulator
attach.d is the front end. It connects to a particular terminal through a unix domain socket and forwards the output from the active screen out to the actual terminal. It also sends messages to the backend process telling it to redraw from scratch and a few other things (and more to come, my thing isn't perfect yet).
https://github.com/adamdruppe/terminal-emulator/blob/master/attach.d
My terminal.d library provides an event loop that translates terminal input and signals. One of them is HUP signals, which are sent when the controlling terminal is closed. When it sees that, the front-end attach process closes, leaving the backend process in place:
https://github.com/adamdruppe/terminal-emulator/blob/master/attach.d#L709
When attach starts up and cannot connect to an existing process, it forks and creates a detachable backend:
https://github.com/adamdruppe/terminal-emulator/blob/master/attach.d#L454
By separating the front end and backend into separate processes, closing one leaves the other intact. Screen does this too: run a ps aux | grep -i screen. The all-caps SCREEN processes are backends. Frontends are lowercase screen processes.
me 3479 0.0 0.0 26564 1416 pts/14 S+ 19:01 0:00 screen
root 3480 0.0 0.0 26716 1528 ? Ss 19:01 0:00 SCREEN
There, I just started screen and you can see the two separate processes. screen forked and made SCREEN, which actually holds the state. Detaching kills process 3479, but leaves process 3480 in place.
The backend of mine is a full blown terminal emulator that maintains all internal state:
https://github.com/adamdruppe/terminal-emulator/blob/master/detachable.d
Here: https://github.com/adamdruppe/terminal-emulator/blob/master/detachable.d#L140 it reads from the socket attach talks to, reads the message, and forwards it to the application as terminal input.
The redraw method, here: https://github.com/adamdruppe/terminal-emulator/blob/master/detachable.d#L318 loops through its internal screen buffer - stored as an array of attributes and characters - and writes them back out to the attached terminal.
You can see both source files aren't terribly long - most the work is done in the terminal emulator core. https://github.com/adamdruppe/terminal-emulator/blob/master/terminalemulator.d and, to a lesser extent, my terminal client library (think: custom ncurses lib) https://github.com/adamdruppe/arsd/blob/master/terminal.d
Attach.d you can see also manages multiple connections, using select to loop through each open socket, and only drawing the active screen: https://github.com/adamdruppe/terminal-emulator/blob/master/attach.d#L300
My program runs a separate backend process for each individual terminal screen. GNU screen uses one process for a whole session, which may have multiple screens. My guess is screen does more work in the backend than I do, but it is basically the same principle: watch for input on each pty and update an internal screen buffer. When you run screen -r to attach to it, it connects through a named pipe - a FIFO in the file system (on my gnu screen config, they are stored in /tmp/screens) instead of the unix socket I used, but same principle - it gets the state dumped to the screen, then carries on forwarding info back and forth.
Anyway, I've been told my source is easier to read than screens' and xterm's, and while not identical, they are similar, so maybe you can get more ideas browsing through them too.
I'm not even sure whether I've framed this question correctly. Let me explain my situation.
I have an Application hosted in a OpenVMS environment which is being accessed via Telnet. I'm in need to programmatically accomplish certain tasks.
So far I could send and receive messages using a C# Telnet Client. I am able to execute tasks by sending commands and receiving responses. But for one task, I have to edit a Form to change some information. The command looks like below
>modify page <page_no>
As soon as I enter the above command, the entire terminal gets loaded with this Form, I have to use page-down to go through the fields, press enter to edit the text and use Ctrl-Z to save it.
I'm not sure how to accomplish this task programmatically.
I'm not familiar with telnet or VxWorks. I'm not sure the above is a feature of Telnet or OpenVMS. Kindly help.
This should be easy to figure out thanks to the clear text of telnet :D It shouldn't matter what platform your target is running. All you have to remember is that special keys like ctrl-z or page down, are just chars in the data stream. Ctrl-z is typically 0x1a, and I am not sure what page down is off the top of my head, but here is how you can figure it out:
Get wireshark http://www.wireshark.org/ and install it if you don't already have it.
Start wireshark up and capture all traffic on your NIC that will carry the connection to the target.
Start a normal telnet session to the target and issue all of the commands (including the page downs and the ctrl-z).
Stop wireshark capture and then filter out everything except telnet communication between you and the target.
Look at the data that was sent to issue the ctrl-z, and page downs.
Put those chars in your telnet stream when you are ready to issue those commands.
Easy.
Good morning. I have an application that queries a REST source. It needs to run continuously, capturing data which is refreshed every five minutes, without fail. My solution is Task Scheduler, where the app is set to launch on server boot. Once launched, it uses a timer to re-query periodically. The TS task is set to repeat every five minutes, with the check box "if app is already running, do not start another instance," so if the app crashes it should restart automatically within five minutes.
This works fine, but TS launches the app invisibly. I'd feel warmer and fuzzier inside if I could see the app, just as if I'd launched it myself. Also, if I need to close it (e.g., to post a new exe), I have to kill it via Task Manager; ouch. I've gone over the TS options a dozen times for some kind of "launch in foreground" option, but none exists. Can anyone tell me what I'm missing?
Notes:
From my web searches, it's clear that an app is only allowed to interact with the desktop if it's running under the same user account... but it is, I'm using my AD account, not SYSTEM or another local account.
It's acceptable for the app to only be visible to me, though even better would be if other users could also see and interact with it. I suppose the only way that would work would be if each user had their own monitor app which just reflected results exposed from a single invisible app which actually did the work.
I get the same behavior if I start the TS task manually or if it launches on boot automatically.
"Run only when the user is logged on" won't do, as I need it to resume even if the server restarts in the middle of the night.
I had been launching the app with a little PS script, so I could send a notification if the app failed to launch at all, but there's no change if I have TS launch it directly.
I suppose the proper solution would be to write this as a service. I put some time into that, but I haven't done that before and couldn't get it running. If the consensus is that that would be a better approach, I'll give it another try.
Any ideas? Thanks!
If you set the task to "run only when user is logged in" then it will be visible for you if you uncheck the "hidden" box.
If you have the "Run whetever user is logged on or not" choice checked, then it will be hidden even if you uncheck the "hidden" box. The implementation of Task Scheduler doesn't allow you to run programs in the foreground if you aren't logged in.
To solve this you can create a user that does AutoAdminLogon and start the application with the Startup script. By doing it this way, you will make the server log in with this user on boot and start the program you want.
If you then want to check how it's going or so, you can login as that user or switch to that session.