I set a couple dozen of programs as my auto-soft engine for any time I log in to develop the open Linux script. Usually the waiting time from one command to another is fed to the backup generators; I can only graph on a couple dozen tab windows at once, while leaves another couple dozen updating themselves when I work on the next batch. This time, however, I had some tabs slip into the frame at a crucial embarkation between two relaying lines in reference to a third program and remained there flat for the while in which the screen was on. Had to reboot it and here I am, working on it again, though having to recover lost data, even within the archives.

The question is, even after using the Veritas recovery system, the two command lines mentioned above are still over-charging the hardware, leading me to reboot the system a couple times only to get this message through (Yay for Veritas RS). The Linux OS drifts off into my spare hardware supplies, when all of them should be up and running.

How do I make pinging commands sync in with the ceaseless streaming development of Linux, in accordance to its user data base? In other words, how to esc-a-late a programmed event into the next without minimizing a variety of tab-windows to load and execute the updating status?

Any input much appreciated,
saywhat

 

It is very difficult to tell what your question is. It looks like you are asking some questions about shell scripting. I will try to take a guess at what you are asking though.

1) To see if a process is running, read up on the "ps" and "pidof" commands.

2) To stop a running process which is uncooperative, read up on the "kill" command.

e.g. if you write the following as a bash script to stop a shell script called sleepy.sh, it will find the PID of it and then use that to kill (stop) it.

#!/bin/bash
badprogpid=`pidof -s -x sleepy.sh`

kill -9 $badprogpid

3) To run a program in the background, add an ampersand ('&') after it in the bash script used to start it.

e.g. Assume the following is a bash script called "t.sh"

#!/bin/bash
sleep 2
echo This is t.sh

Assume the following is a bash script called "q.sh"

#!/bin/bash
./t.sh &
echo This is q.sh

Assume the following is a bash script called "r.sh"

#!/bin/bash
./t.sh
echo This is r.sh

If you run "q.sh" it will print the following:

This is q.sh
This is t.sh

If you run "r.sh" it will print the following:

This is t.sh
This is r.sh

Note the different order in which the output appears.

Let's try something more complicated.

Here's a program called "sleepy.sh". It simply prints a message, waits 15 seconds, prints another message, and exits.

#!/bin/bash
echo This is sleepy starting up.
sleep 15
echo Sleepy stopped by itself.

If we start it as follows:

./sleepy.sh

we have to wait until it's done before we can do anything in that terminal.

If we start it the following way though:

./sleepy.sh &

it will run in the background and we can run other commands before sleepy.sh is done. For example, if we run the following command while sleepy is in running in the background:

pidof -s -x sleepy.sh

We will get a response of a number (e.g. "8123") representing the PID (process ID).

If instead we run our kill script from above (which we will call 'tk.sh' in this example), we will kill sleepy and it will never print the second message. <pre>
./sleepy.sh &
[1] 8164
This is sleepy starting up.
./tk.sh
[1]+ Killed ./sleepy.sh</pre>
A "kill -9" is the most aggressive of the kill signals you can send. That is a "SIGKILL" signal. Since "sleepy" is a fairly cooperative program, a simple "SIGTERM" would do the job as well. Just replace "kill -9" with "kill -15" in the kill script above.

To get a complete list of signals, type the command "kill -l" (that's a lower case "L", not a numeral "1"). You can google an explanation of the various signals. Unix programs can send signals to each other if they know or can find the PID of the target they want to send it to. That's a simple way of communicating between them. Many programming languages will have a way of sending and receiving signals as part of their standard library. You can define your own signals as well as using the standard ones.

If the above isn't what you want to know, then try to phrase your question more clearly.