Why do some programs, show a caret when executed, and pause, waiting for input?

kandaris

New Member
Joined
Oct 25, 2021
Messages
5
Reaction score
1
Credits
53
My instinct tells me that the program is waiting for a subsequent command or terminator/endline character, but I can't figure out what it may be waiting for.
 


OP
K

kandaris

New Member
Joined
Oct 25, 2021
Messages
5
Reaction score
1
Credits
53
ipfs daemon

for instance... it doesn't recognize control characters like backspace, so I assume its waiting for something I'm not aware of. I've searched for the meaning of this behavior in the past when using other programs and I've usually just worked around it but that's not possible in this case. I need to really understand whats going on in general so I approach it correctly in the future. l'm sure its just something I'm ignorant of but I'm not even sure if I'm asking the right question.
 
OP
K

kandaris

New Member
Joined
Oct 25, 2021
Messages
5
Reaction score
1
Credits
53
Here is the output I'm getting for context and the end of it includes the output with a few backspace attempts. Its like the input is in a different mode so it does't act like a backspace.

Initializing daemon...
go-ipfs version: 0.10.0-64b532fbb
Repo version: 11
System version: amd64/linux
Golang version: go1.16.8
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/udp/4001/quic
Swarm listening on /ip4/192.168.1.39/tcp/4001
Swarm listening on /ip4/192.168.1.39/udp/4001/quic
Swarm listening on /ip6/2600:6c4a:87f:ca5b:0:a55d:5435:639/tcp/4001
Swarm listening on /ip6/2600:6c4a:87f:ca5b:0:a55d:5435:639/udp/4001/quic
Swarm listening on /ip6/2600:6c4a:87f:ca5b:65fe:7158:c05d:e0f7/tcp/4001
Swarm listening on /ip6/2600:6c4a:87f:ca5b:65fe:7158:c05d:e0f7/udp/4001/quic
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/::1/udp/4001/quic
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/127.0.0.1/udp/4001/quic
Swarm announcing /ip4/192.168.1.39/tcp/4001
Swarm announcing /ip4/192.168.1.39/udp/4001/quic
Swarm announcing /ip4/47.26.153.240/udp/4001/quic
Swarm announcing /ip6/2600:6c4a:87f:ca5b:0:a55d:5435:639/tcp/4001
Swarm announcing /ip6/2600:6c4a:87f:ca5b:0:a55d:5435:639/udp/4001/quic
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/::1/udp/4001/quic
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
ipfs daemon && ipfs swarm addrs^[[D^[[D^[[D^[[D^[[D
 

KGIII

Super Moderator
Staff member
Gold Supporter
Joined
Jul 23, 2020
Messages
4,064
Reaction score
3,739
Credits
32,636
OP
K

kandaris

New Member
Joined
Oct 25, 2021
Messages
5
Reaction score
1
Credits
53
sure, thanks but I am aware that, that command will break any program... its just that some daemons or programs seem to get into this state and are waiting for something else. Or... maybe a slow process that does not come back to the terminal right away?
 

JasKinasis

Well-Known Member
Joined
Apr 25, 2017
Messages
1,321
Reaction score
1,870
Credits
8,343
It ultimately depends on the program.

When running, all programs will block the terminal until they finish running, or until they are manually stopped using ctrl+c - or killed from another terminal via the kill command.

This is especially the case with daemons, which typically run perpetually. That's probably what you're experiencing here with whatever daemon you are running in the terminal.

With things like daemons - if you don't want the terminal to be blocked until they are finished, then what you do is run the daemon in the background by appending an & at the end of the command.
e.g.
Bash:
somedaemon --option1=value1 --option2=true &
Above is a completely contrived example - we start somedaemon, passing some parameters and using an & at the end to run it in the background.
When running a process in the background - you will be able to continue to use the terminal and enter other commands/run other programs.

But any time the daemon outputs something to stdout - it will end up being echoed in the terminal that started the process.
So you might occasionally get interrupted by some messages from the daemon.

One way around that would be to redirect all of the output of the daemon to a file.
e.g.
Bash:
somedaemon --option1=value1 --option2=true &> /path/to/some/logfile &
The &> redirects stdout and stderr to the specified log-file.

Or you could completely ignore the output from the daemon by redirecting it to /dev/null:
Bash:
somedaemon --option1=value1 --option2=true &> /dev/null &
That way all output from the daemon is hidden.

Also - whenever you start a process in the background, the terminal will display the Process ID (PID) of the process.
You can also use the bash's jobs builtin command to see any background processes that the current terminal is running. Using the -l parameter with jobs shows the PIDs of the processes along with the usual information (handy in case you forget the PID of the job you started in the background).
To see all of the options available for the jobs command, use the command help jobs.

Additionally, you can use the kill command to send signals to processes in order to kill them, or stop/resume them.

Sometimes terminal based programs do stop and wait for input.
For example some programs expect input from a file. And if they don't receive a path to a file in their parameters - they will use stdin as the input file.
So, in lieu of input from a file - these types of programs will continue to process anything you type on the keyboard until you hit a key combo like CTRL+D - the end of file key-bind, or CTRL+C - which typically kills the program, or CTRL+Z, which suspends the program.

If you suspend a program with CTRL+Z - it will be paused/suspended and listed by jobs as a stopped process.
To resume the process in the foreground, you can use the fg command.
To resume the process in the background, you can use the bg command (though, restarting a process in the background is really NOT a good idea if the program expects interactive input from the user!).
And again - the kill command can be used to send signals to the process, in order to control its execution, or kill the process.

Hopefully that all makes sense and is useful to you!
 
Last edited:
OP
K

kandaris

New Member
Joined
Oct 25, 2021
Messages
5
Reaction score
1
Credits
53
Dude! that was it I was trying && and sort of getting near it but it was in the back of my memory that there was this command. It was & not && since of course && strings commands together. This was what I was looking for, thanks so much! :)
 

JasKinasis

Well-Known Member
Joined
Apr 25, 2017
Messages
1,321
Reaction score
1,870
Credits
8,343
Dude! that was it I was trying && and sort of getting near it but it was in the back of my memory that there was this command. It was & not && since of course && strings commands together. This was what I was looking for, thanks so much! :)
No worries! Glad to have helped!
 
$100 Digital Ocean Credit
Get a free VM to test out Linux!

Members online


Top