LinuxQuestions.org - question about shell-script programming

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - question about shell-script programming (https://www.linuxquestions.org/questions/programming-9/question-about-shell-script-programming-383655/)

question about shell-script programming

Hi all,

i would like to write a shell-script which should do the following:

For an example the scripts name ist TEST...you run

....#TEST & (to put it to the background)

The script is running in a loop and waiting for a special command, f.e "mycommand"..

Due to this fact the script is running in the background I can further work on my console prompt and when I write the "mycommand" the script will identify that I wrote "mycommand" and will do what it have to....

So I need a way to catch my console-input by a shell-script....Anybody an idea??

Thanks in advance

gsx

You don't need a shellscript for that. Just use command 'fg' to get back to the program you've put in the background.
And catching console input from within the shell is a costly operation. I've written something like that in perl ( using the select system call ), but system-load was going very high, due to a lot of interrupts and the overhead a scripting language has...

I don't have the same experience as fvgestel in capturing user input, but I come to the same conclusion: don't.

This is just far too complicated to mess with. I'd suggest an alternative. This might be useful:
1. Start the program by running it in the background
2. Have the script periodically check for the existence of a specific file (this is your flag)
3. Create an alias for your "mycommand" so that it will touch/create the file the script is looking for (and anything else it needs to do)
4. When the script sees the file is present, perform whatever action is necessary
5. Have the script delete the flag-file when it's done

Using something like that avoids the complexity of sharing user input between your script and the shell, and it accomplishes the same thing (from the user's perspective). The difference is, there's some added latency. If your script checks for the file every X seconds, then there's the chance the script won't perform its task for X-1 seconds after "mycommand" is issued. X can be reduced to minimize this delay, but the smaller X gets, the more time and resources spent checking for the file.

Another alternative would have the script capture a signal. I don't have any experience with signal handling in scripts so I can't help there. However, a signal would cause the script to immediately begin its task after "mycommand" is issued. This method would still require aliasing "mycommand." The alias would probably need to contain a kill command to send the specific signal.

fvgestel, dark_Helmet....

thanks a lot for your good ideas...
I thought about it thats to difficult to catch the console prompt by a shell-script ;)

I think your idea with the alias and file-checking is a good way for my issue..
Its time to try it :)

thx

gsx

Ok, here is my test-script:

Code:

#!/bin/bash





#Variables

weiter="no"







# Aliases for root 

#if [ -e "/root/.bashrc" ]; then

#        cat alias.conf >> /root/.bashrc

#else

#        echo

#        echo "An error occured..."

#fi





while [ "$weiter" != "quit" ]; do

        sleep 1

        if [ -e "/tmp/gsx.flag1" ]; then        #Info: When alias "d" is pressed, in /tmp the file "gsx.flag1" will be created!!! 

                echo                                          

                echo "[daemon] [start/stop/restart]:"

                read  a b

                /etc/init.d/$a $b

                rm /tmp/gsx.flag1

                        

                

        

        elif [ -e "/tmp/gsx.flag2" ]; then        #When alias "q" is pressed, in /tmp the file "gsx.flag2" will be created!!! 

                echo

                echo "Quitting gsx-daemon...."

                weiter="quit"

                rm /tmp/gsx.flag2

                exit 0

        fi

done

exit 0

I start the script in the background:

lowrider:/home/gsx/scripts# bash test &
[1] 6266
lowrider:/home/gsx/scripts#d
[daemon] [start/stop/restart]:
apache2 start
.
.
# Then the apache2-script show me the usage-text and don´t start the daemon!!
# Additionally the job will be stopped

[1]+ Stopped bash test

lowrider:/home/gsx/scripts#

--> What´s the error in the script? Why the daemon could not be started...when i type "/etc/init.d/apache2 start" (at normal cmd-prompt) it works fine..
--> When the job is stopped (like above) how to get it running again? First kill and restart or is there aa other way?
--> When i press "q" to exit the script (still in background) the script exit´s but i don´t have an command prompt. I have to type in a further command and the the job will be closed...is there any possibility to exit the script immediately?

Thx in advance
gsx

incidentally, it's a bad idea to call programs and scripts test
as often you will pick up a shell built-in or /usr/bin/test by mistake.

the name test was only a given name for this little "Test"-Script...
when the script run i will only take the code of this script...

But I think the error of daemon-use is not due to the fact that the script is named "test"..

gsx

this seems peculiar.
Why in the background?

If it responds to user input why not just use a shell script?
seems pointless it being in the background to me.

can you explain further?

Ok...

this issue we talking about is only a small part...
I am writing a script which do a lot of things....f.e. Configuring the Xserver, starting daemons, change your grub-settings and so on.....

I want to give the user two options to use the script:

1. Like you said only as shell-script (work with parameter like $1,$2,...)
2. To load the script at boot into background and to use just a lot of simple commands to do the things for you...it�s more comfortable...

this script above is for testing only...

gsx

ok.
nice and simple then!

good luck! ;)

this is a related post i was in:
http://www.linuxquestions.org/questi...hreadid=351711

this furthers helmet's idea,

thats a good info....thx a lot..