I have a compiled program written in C++ for a UNIX environment which has this kind of structure:

int main(){
    std::cin >> buffer;

Loading the engine takes quite a while, so I'm trying to start the program in the background first, then send the input whenever I need to.

Running the program with the standard ampersand appended at the end seemingly does not make the program run in the background, but rather halts at std::cin until an input is received from the console, and stops after an input is accepted from the console.

How do I execute the program such that the program runs continuously in the background and receive input and execute the function whenever it is needed?

EDIT: The final product is a small device (RaspberryPi) which recognizes speech, and does something based on the words recognized. The program that I have is the part where the device does something based on the word input, and the word input corresponds to the variable buffer from the code snippet above.

So the std::cin part is a dummy line code that I'm using for testing out that my part of the code starts up in the background process (to load the engine) and does whatever it is designed to do.

EDIT 2 : To clarify what I’m trying to achieve, the program takes an input from a speech recognizer and does things (e.g. synthesize speech from input, send out signals to LEDs, etc.). The text input can be taken directly from the console (which my code is currently doing), or some other method that I’m not knowledgeable in. The only thing that the input adheres to is that it must be a text, and is sent from another program that recognizes speech (which is handled by some other developer). So the exact method isn’t specified. All I have to worry about is my side of the program, which executes a function from a text input (i.e. buffer from the code snippet). So the general structure would look something like this:

Int main(){
    buffer = ReceiveInput();

Where the ReceiveInput() part is currently implemented as std::cin. It really can be any method, as long as the engine is loaded once in the beginning, and the program is able to perform ExecuteFunction from an input until the device is turned off.

  • The std::cin part is a dummy line code that I’m using for testing …  the program … halts at std::cin until an input is received from the console …  WHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT?  Your program is failing because of a line of code that’s there only for testing?  Why don’t you just take it out?  What you are saying doesn’t make any sense to me.  Please try to explain this better (in the question, as much as is practical).  How do you expect your program to get audio input (from the microphone, presumably)?  Are you running your program with stdin redirected, or piping something into it? – Scott Aug 28 '15 at 5:14
  • @Scott Sorry for the confusion. I'm in charge of a small part of a bigger project, and because of my mediocrity with unix environments, the other developers suggested that I modify the program to be able to handle a text input, and they will adjust their code to synchronize with mine. So the code isn't strictly confined to std::cin; it's the only function that I could think of. – stock username Aug 28 '15 at 7:02
  • Well, I still don't understand.  If the other developers suggested that you modify your program to be able to handle text input, and they promised to adjust their code to synchronize with yours, does that mean that, when everything is integrated, their program will be piped into yours?  If so, then you should test your program with input coming from a pipe. – Scott Aug 28 '15 at 8:15
  • @Scott Yes, I think that's sort of the direction that this is going. How do I add a function in the while loop that accepts input from a pipe? – stock username Aug 28 '15 at 8:39
  • When everything is tested and integrated, the final command line for the system will be something like their_program | your_program &.  Since the pipe (from their program) is now the standard input (stdin) to your program, the code you have now to read from std::cin should work, unchanged.  Test with your_testscript | your_program &, where your test script does things like sleep 600, echo "The quick brown fox ...", sleep 420, echo "jumps over the lazy dog.", ... – Scott Aug 28 '15 at 12:58

This is awkward and inconvenient, but possibly less so than the other answers:

Every time your program asks for input:

  1. Get to a shell prompt — and I mean the shell that launched your program.  (I.e., the fact that you're not just running your "engine" program in the foreground suggests that you're using the terminal for something else, like maybe editing files.  Every time your program asks for input, you'll need to save and quit out of the editor, and get back to your primary shell.  Or you may be able to suspend the editor; but that makes the next step more complicated.)
  2. Type fg (followed by Enter, of course) to bring your background job into the foreground.  If you have multiple background jobs (as suggested above), do what you need to do to bring your "engine" program into the foreground.
  3. Interact with the program.
  4. When it's ready to resume running (computing, etc.) for a while, press Ctrl+Z, and then bg (followed by Enter).

Repeat the above as long as the program runs.

|improve this answer|||||
  • The catch is that there won't be anyone handling the console. It's a small program that's going on a Raspberry Pi. It recognizes speech and does something based on what's recognized. The program that I have is the part where the device reacts to the recognized word input (where the recognized word input is the buffer variable from the sample snippet above). – stock username Aug 28 '15 at 4:03
  • Your comment to Peter asks, “Aren’t daemons a type of process that can’t handle direct input from the console?”  So, do you want/need your program to be able to read from the console, or don’t you? – Scott Aug 28 '15 at 5:15

Unlikely that is possible. In such cases typically you need to listen network port, accept() connection and read from it data, and do whatevet you need. Then you need some client app also to send data. This is how background apps typically work.

|improve this answer|||||
  • 1
    A background process reading from its controlling tty automatically receives SIGTTIN, which exists for the purpose of stopping bg programs that try to read from the terminal. So yes, make a daemon and a client, like emacsclient. The client can start the daemon if not already running, so the user doesn't have to care about it. See gnu.org/software/libc/manual/html_node/Job-Control-Signals.html for details on SIGTTIN. – Peter Cordes Aug 27 '15 at 4:53
  • @PeterCordes I'm relateively new to daemons so I may be blatantly wrong. Aren't daemons a type of process which can't handle direct input from the console? If so, then how would I go about structuring the whole program? The engine part and the function that needs to be executed share a lot of the classes and functions, so separating them wouldn't be so efficient, nearly impossible. – stock username Aug 28 '15 at 3:56
  • @5422time: Instead of doing I/O to/from the terminal, the daemon would do I/O to a client that connected to it. You can have the same program be able to act as a daemon or a client. If it starts up and detects that no daemon is running, it forks. The forked process daemonizes itself (closes stdin/stdout/stderr), then makes a Unix socket like /tmp/myprog-uid$UID.sock. The "client" part only has to send data to the daemon, and print the result on the terminal, so it can be a separate simple program. – Peter Cordes Aug 28 '15 at 4:06
  • Look at how emacsclient -c --alternate-editor= works. It starts emacs if needed, otherwise starts a new frame for the existing emacs. – Peter Cordes Aug 28 '15 at 4:07

You would need to send your application some wake-up call, so it knows when to listen to the input, and where to expect it(since running it in background separates it from the terminal process). The better solution would be(imho) creating separate program that would serve as an interface to the engine - as engine looks like your problem. Provide set of functions to communicate with it, and write simple script that when run, will send input to the engine. Engine will run in background, and other programs will just connect to it. That's the best thing I can come up with at the moment.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.