27

You cannot open /dev/pts/0 because it's owned by root, and after you su-ed into another user you're no longer able to open it via its path, but you're still able to use it via the opened handle to it, which was inherited from the parent process. script /dev/null will create another pty, owned by the current user. Anyways, that bug/limitation seems to have ...


14

This "feature" has existed in systemd previously, but the systemd developers decided to effect a change in the default, to enable the setting for termination of child processes upon log out of a session. You can revert this setting in your logind.conf (/etc/systemd/logind.conf): KillUserProcesses=no You can also run tmux with a systemd-run wrapper like ...


10

This was confusing to me initially as well. I then re-read the local screen man page for the SYNOPSIS -- the online man page does not give a synopsis) -- and noticed that it said: screen [ -options ] [ cmd [ args ] ] ... which led me to believe that it wanted to see the cmd and args as independent arguments. Since you gave that first argument as a quoted ...


4

Yes, there is. Although there is not (currently) a bindkey flag that affects only copy-mode (not command-mode also) there is still a way to get similar results, though it means learning a new syntax for doing so. The fix The markkeys command affects copy-mode only, and will not affect command-mode behaviors. It's pickier about what characters it will ...


3

screen processes don’t maintain socket connections while they’re running; they open and close socket connections as needed when they have messages to send. Thus, when you run screen -r to reconnect to an existing session, it connects to the existing process using a socket, negotiates various settings, and when it’s good to go, attaches to the appropriate ...


2

I don’t work with Arduino devices, so I can’t be of specific help, but in lack of other answers I can try and give you some general hints (for the UNIX/Linux side) as to how address your particular problem. Unfortunately there’s no setting you can give to your serial port to make it send data in lines. That is a responsibility of the application, i.e. the ...


2

I don't think there is any option for that -- other than looking through the process list: screen -r $(pgrep -f '\<SCREEN.* -t name\>') On *BSD something different is needed: screen -r $(pgrep -t- -f '\<screen.* -t name\>') The -t- option of pgrep directs it to match only processes with no controlling terminal, in this case only the screen ...


2

Yes, but only with the cooperation of your terminal emulator. Terminal emulators send escape sequences (or in a few cases a single control character) to indicate the press of a function key. See the “terminal — input” section of How do keyboard input and text output work? for more details. You need to configure your terminal to send a unique escape sequence ...


2

Let's start with just the first couple of lines of your script. The issue affects all of them but it's easier to deal here with just one. #!/bin/bash screen -dmS xccda "$(cd /root/constella && ./daemon.sh)" If you're declaring this as a bash script, don't use sh to run it. Either set the permissions and run it as ./main.sh or else use the right ...


2

On a local machine, I don't have to worry about unstable network connection between computer and terminal, and don't have to share session with other users. But you can always close your terminal window inadvertently. Or you can restart your X server. I can use nohup or disown, if I want to make a process survive the termination of its parent, or ...


2

man screen: ├─────────────────┼─────────────────┼─────────────────────┤ │C-a a │ (meta) │ Send the command │ │ │ │ character (C-a) to │ │ │ │ window. See escape │ │ │ │ command. │ ├─────────────────┼───────────...


2

In general, by default the only difference is that it would receive a SIGTTIN (or SIGTTOU) signal if it tried to read (or write) the tty while being in the background. Other differences as to priorities or higher context switches depend on your shell (or screen) if it willingly does anything of that sort, such as changing the process’s “nice” number or ...


2

Ctrl+C sends the INT (interrupt) signal to the process currently in the foreground. This is an important signal to be able to send, so the best thing would be to just learn not to press that key combination by mistake. You can also remap that key combination so that you have another control sequence that sends the INT signal. For example, you may make ...


2

After starting your screen session, run this (in another terminal): while sleep 10s ; do screen -X next ; done The -X option sends commands to an existing screen session, and next simply advances to the next window. So if your session only has the two windows, then this will switch from one to the other.


2

Nice idea. I'd create a wrapper, say /bin/my-screen that would look like this: #!/usr/bin/env sh screen -d -RR Make it executable and add it to /etc/shells: echo /bin/my-screen | sudo tee -a /etc/shells Make it the default shell: chsh --shell /bin/my-screen Notice that some terminal emulators such as xterm do not run shell defined in /etc/passwd by ...


1

I can reproduce this with this Dockerfile: FROM centos:latest RUN yum -y install screen && rm -rf /var/cache/yum CMD screen -S session1 sleep 99999 when I run it with docker run <imageID> I get Must be connected to a terminal. Screen needs a terminal (tty) to function. The solution is to add -tid to the run flags, from the help: -d, --...


1

Does your user account eric have the permission to use /dev/ttyUSB0? To find out, please run ls -l /dev/ttyUSB0. The output might look like this: $ ls -l /dev/ttyUSB0 crw-rw----+ 1 root dialout 166, 0 Jul 9 08:55 /dev/ttyUSB0 The characters at the left-most column are the file type and permissions information: The first character is c, indicating a ...


1

screen -D -m starts a new session in a detached state without forking a new process. The command will not terminate until that new screen exits. You can still put the command in the background with Ctrl+Z followed by bg, and then check what name it got with screen -ls (it will say (Detatched) at the end and also mention the time it was created). The name ...


1

Seret! Let's see if I can help. I'm thinking in your shoes, I'd look to see if the remote system has the "tar" and "base64" or "uuencode" programs installed. If so, I'd start a fresh terminal on my workstation, start "typescript" or "script" in it - not screen for this - and then connect that to the remote server over serial. Now you are recording to a ...


1

This sounds similar to this screen bug detailed for Ubuntu. You are sharing the /run directory between your host and chroot, but I suspect they are running different versions of screen and the the Ubuntu one is exhibiting this bug and should be updated to a version that does not have this problem. If that does not help fix things, post the versions and ...


1

This isn't possible with tmux yet. You can only lock the terminal so far. The developers argue something about if someone has access to another shell on the system then you are toast anyway. However, I've come up with a quick solution using file permissions and attributes to lock things up. I've put it together into 3 bash files which you would have to add ...


1

Each Screen session is its own “server”; these are the “SCREEN” processes, and they are the processes which continue running when you detach from a session. The “client” is a “screen” process which connects to the corresponding session and allows you to interact with it; these are short-lived (relatively speaking), and only last as long as they are attached ...


1

Which should I use if I run tmux inside kitty? When running tmux then you must use TERM=screen, TERM=tmux, or one of the derivatives e.g. TERM=screen-256color or TERM=tmux-256color. man tmux(1) states ... The TERM environment variable must be set to “screen” for all programs running inside tmux. New windows will automatically have “TERM=screen” added ...


1

When data was read from pipe it was gone from pipe. I don't think that it's possible to have multiple readers which can read same data at same time. So when screen is attached, probably screen process read data before tail/cat that you use.


1

All you need to do is to use the session name as an argument on the command line: screen -r SESSIONNAME If you have more than one screen with the same session name, you'll also need to specify the PID, like so: [jenny@sameen ~]$ screen -r test1 There are several suitable screens on: 23669.test1 (Detached) 23594.test1 (Detached) Type "screen [-d] -...


1

This seems to be a timing problem, in that nohup does not have time enough to disable signals before it is signaled by one of the parents. You can see this by adding strace -o /tmp/s -ff in front of the screen command and then in one of the log files /tmp/s.* you see ... access("/bin/nohup", X_OK) = 0 stat("/bin/nohup", {st_mode=S_IFREG|0755, ...


1

Also there is a very simple handy cheat-sheet designed for screen using its own help command‌ (Ctrl + a:help or Ctrl + a ?) which helps to remember all shortcuts and their actions: In your case the shortcut key A is assigned to keyword title on its help. (Just needs to remember all documented shortcut keys require to press Ctrl+a or (C-a) before being ...


1

Another way to do it is to attach the screen first: screen -r <pid or name> and then: Ctrl+A, H It will start logging into screenlog.0


1

For those who might be looking for a bit more reference than the selected answer provides, there was an another good answer to this question over on StackOverflow: https://stackoverflow.com/questions/27307815/how-to-change-the-starting-directory-of-a-tmux-session Which provides ways you can do it without leaving the session, and for those who use tmux in a ...


1

if test ! -z "$STY" then echo "I am running in GNU Screen" fi Is a quick solution which does not require external programs.


Only top voted, non community-wiki answers of a minimum length are eligible