Send command to another terminal and press enter
 

I am struggling here to do this over a remote shell , there are a few tricks that almost do the job , but when it turns to be the login shell they don't work .

I already tried ttyecho without success because ttyecho sends a new line with "-n" switch but login does not interpret that command as an "ENTER" .

I also tried :

and i get the root there and the new line , but it does not work .

What i need is to send to a different tty the login and password over a remote shell , does anyone have an idea in how to do it ?

Are you referring to physical terminals, or the emulated ones accessible via Ctrl+Alt+Fn keys on Linux?

emulated terminals on a server .
my server does not go to a gui interface , i did not want it that way , it goes directly to a shell waiting for username and password , i also dont want to remove that .
What i need is to connect remotely to that server over ssh (witch i already do) and insert the username and password so i can start a network script on it .
Basically my server is right next to me , i could do that by connecting my keyborad by usb to it and do all this stuff , but after i done i have to remove the keyboard from server to connect again into the machine i usually work .

ssh into it and run the script

https://askubuntu.com/questions/8653...ng-ssh-session
https://stackoverflow.com/questions/...ch-the-session
https://www.tecmint.com/keep-remote-...disconnection/

Here it is the problem , i cant run the script over my ssh session because i will not be connected to the server much time , and when i disconnect my ssh session the script will stop .
The script i want to run must be running on tty1 witch is the main display of the server .

What i need is to send username and password to server so the main tty session can start .
This is all i need here .

Note : If it was simple then i already had done it .

Try a terminal multiplexer like tmux or screen. That will allow you to start script and leave it running even after you disconnect. As a bonus when you re-attach you see all the output that happened while you were gone.

Even though I grew up on screen, I recommend tmux. There's so much you can do with it, that there is too much to even begin to describe.

The gist would be to start a new session:

Then to re-attach,

Sessions and windows can even be given names to help identify them in scripts or just label them on the screen. So you can even make a script that lauches tmux and then launches your other script within it.

Perhaps openvt would be an option (ssh remotehost 'trap "" HUP; openvt someprogram &' or similar).

https://linux.die.net/man/1/openvt

I second Turbocapitalist on that

my personal prefrence is screen, but I don't really remember why I didn't get on with tmux.. I may give it another try

that will try to reattach ( -x ) to an existing screen, if none then it starts a new one.
the -A adjusts the 'window' size, saves you having to do "^a F"
( ^a by default is mapped to Ctrl+a )

you 'detach' from screen with "^a d", this then terminates the ssh session.. but screen and any programs/scripts you have running are still running

if you are in the habit of using Ctrl+a to return to the begining of a line in a bash shell you will soon be double tapping a, even when not in screen ;)

To open a new window, ^a c
the switch back and forth, ^a ^a ( not a typo, you do it twice )
too many things to list, so I will stop ( many I simply don't know )
I should probably read the manual

you can attach to another screen from in screen, but it gets confusing :D

below is my ~/.screenrc
I have bolded the bit laptap users may be interested in
it gives battery level, handy if you are on a console ( no X running )

you can find plenty of screenrc examples on the web

you can also start screen with systemd, and have it start things for you



yeah, screen or tmux does what you need

oh, hold on I missed that, it *must* be run on tty1

I wonder if customising /etc/inittab will work for you.
https://www.tldp.org/LDP/sag/html/config-init.html

inittab 'runs' getty on tty1, which runs login
I guess, and is only a guess atm
You could replace getty with something else..
I imagine it is root the executes that, so you could have a wrapper script
you could use a VM to test that out
probably a good idea to remove the respawn while tesing, if it fails it could get way too spammy.

Working from memory here, but doesn’t the -e switch suppress the return on echo? Try your echo without it.

Working in the same terminal I’ve always used nohup to run jobs in the background. It automagically redirects output to a file and keeps the job running even after the session ends.

(nohup == no hang up)

-n suppresses nl -e interprets control codes ( \e[35;m and so on )

Thanks. I wasn't in a place to look that up when I posted earlier...but I wanted to put nohup in the discussion.

yeah, that is what I used to do before I found gnu screen

but I don't think nohup, screen or tmux are a solution for pedropt.

I might be wrong but I belive they require output on the physical monitor screen

I wonder if screen or tmux can 'replace' getty in the inittab

actually, many years ago I created a 'live' cd for burn testing PCs
it would run mprime for each core/thread
it was most likely tmux I was using to split the screen into 2 or 4 depending on the CPU
Alt+F2 was tailing logs

I must have editied inittab to achive that.

I don't know squat about screen or tmux, but all the servers I've ever administered were headless. My only access has been via ssh (or telnet in the very old days)...so I don't agree. I think that nohup is the solution for the OP:

so
By default, STDOUT is redirected to a nohup.out file, although the script can be redirected (>) normally. see man nohup

So,
ssh to server
login
nohup script
exit

The script will continue to run.

For one, by default it is easier to create, see, and switch between sessions and session windows and session window panes. I find tmux simpler but more flexible. Once you start configuring it and making a lot of customizations, you'll see a bigger difference. It does not have serial line support and it is a bit different to make a shared session. The former can be provided by other single-purpose programs (minicom, cu, etc) and the latter on file system permissions and system groups.

If I were using screen then I usually do like this instead:

That will attach to the existing session (while detaching from any other terminal) but create a new session if none already exists.

The same would be done in tmux in about the same way as you gave for screen above:

I don't have much in .tmux.conf though, just a few global settings. Normally I just set the specifics in the run-time arguments. For example, I don't want 'remain-on-exit' set for all sessions, just in some. I want other sessions in different colors or visual-bell on or off or split windows. Some launch specific programs automatically. And so on, but without affecting the other sessions. For example:

I really ought to look into the fancier stuff though.