New answers tagged

0

When you run screen, it sends (among other things) the strings defined in the terminal description for starting/stopping full-screen operation. These are ti and te (in termcap), smcup and rmcup (in terminfo). When you start screen, or attach to a session, it sends ti (smcup). When you stop screen, or detail from a session, it sends te (rmcup). Depending ...


1

You can attach to the session from "another terminal" (including another ssh connection). That lets you recover anything that was in progress. You can always kill the screen session as you started it, by using sudo to kill the parent process of the screen session (the one named "screen"). The feature only is useful if it is properly configured to begin ...


0

It's possible that screen's autodetach feature is turned off: autodetach on|off Sets whether screen will automatically detach upon hangup, which saves all your running programs until they are resumed with a screen -r command. When turned off, a hangup signal will terminate screen and all the processes it contains. Autodetach is on by default. ...


0

I think this should work: screen -r user_2 -X stuff "you_script.sh" screen -r user_2 -X eval "stuff \015"


0

The answer probably lies with the "nohup" command. Or you can simply add an ampersand (&) at the end of your command to send it to the background and maintain control of the CLI if your script takes a long time. which is why I guess you want to use Screen? Ampersands on the command line


0

If you're using this inside a .shrc file or similar with exec I'd recommend if tmux ls exec tmux attach else exec tmux fi


2

There are a number of technical similarities and differences, but the one difference that should matter to you is that unlike the virtual consoles, using screen, you can attach to a screen session from any terminal connection to that computer: other virtual consoles terminal emulators running in X an ssh (or telnet) connection from another computer All ...


0

I figured it out. What I ended up doing was just resplit the screen and listed all active sessions within screen, and then loaded those CTRL + A, " problem solved


0

Depending on your system your environment variables may not be set. You can either call everything using their full path or add your environment variables by hand. To do this (per man 5 crontab) you can insert variables at the top of your crontab in the standard KEY = VALUE layout SHELL=/bin/sh ...


2

screen -dmS workspace; screen -S workspace -X stuff $'ps aux > output-x\n' I first create a detached session with the -d switch, I called my session workspace. I then send my command to the same session with -X stuff, I am using $'', but you could also use double quotes, but have to do a control M instead of a \n, which I don't like so I normally use ...


0

You can use the disown or nohup usage: How to monitor WGET download progress after closing SSH session


1

screen does not know anything about CtrlAltF1. It only knows about sequences of bytes. The CtrlAltF1 may have meaning to a terminal emulator in which you are running screen (and send an interesting sequence of bytes to the application), but its meaning may be (as in a Linux virtual console) be built-in in a manner which prevents the key from sending data ...


0

After many reading, and thanks to Bibek_G's answer which helped me to find some links on the internets, I finally understood what I need and how to make thing work. Actually, what I want to do doesn't need screen... The right command was : sudo echo 1 > /dev/cu.HC-06-DevB It didn't work at the beginning because I didn't use sudo. By the way, I also ...


0

Here's the manual for screen. Look for the specific command line options to the screen that you're interested in. For example, -r reattaches to a detached screen process. -R reattaches if possible and starts a new session otherwise. I think this is the option you're looking for. So, I'd do: $ screen -R /dev/tty.HC-06-DevB Also from the manual page: ...



Top 50 recent answers are included