Nohup and the standard input

[batonsu]

Hello! I have a simple question. If I run a program with the nohup command, the stdout is attached to the nohup.out file. The question is, where is stdin attached to?

Personally, I have a Minecraft game server running in the background. How can I pass some commands to the server? Executing it whithout nohup is not an option - the server must be session independent.

 

[funky]

Hello! I have a simple question. If I run a program with "nohup" command, the stdout is attached to "nohup.out" file. The question is, where is stdin attached to?

On a Linux box the man page says it redirects it from /dev/null, but there is nothing about that matter on the BSD man page to nohup().

Personally, I have a Minecraft game server running in the background. How can I pass some commands to the server? Executing it whithout "nohup" is not an option - the server must be session independable.

I would rather use sysutils/tmux or sysutils/screen for that (I prefer tmux), so you can always detach and later re-attach a console session.

 

[batonsu]

Thanks for reply. I will check out these utilities tonight.

The fact that stdin is /dev/null brought me to trying this:

$ touch myinput
$ nohup [I]command[/I] < myinput &

Then I tried to

$ echo 'foo' >> myinput

But it gave no result. I expected 'myinput' to become similar to a device file. For example if I echo a string into /dev/pts/0 (or tty) it displays on the screen. But I guess in my case, the program just reads the contents of the file at start, and then forgets about it. Maybe there's a way to make it constantly read the file during runtime, just like if it was a keyboard?

 

[fluca1978]

I've tried this and works:

nohup /bin/echo < /bin/echo "Hello World"

and it works using the first echo (the one in nohup).
Even this is working:

nohup /bin/cat < file.txt

using a csh. I guess you mispelled the background option & in your command.

 

[SirDice]

I expected 'myinput' to become similar to a device file. For example if I echo a string into /dev/pts/0 (or tty) it displays on the screen. But I guess in my case, the program just reads the contents of the file at start, and then forgets about it. Maybe there's a way to make it constantly read the file during runtime, just like if it was a keyboard?

Arguments aren't read from stdin, they are passed onto an application using an array of strings (argv and argc). That array is only parsed when the application starts.

What you are trying to do is similar to this:

cat somecommands.txt | myapplication

Which is the same as:

myapplication < somecommands.txt

Unless myapplication reads from stdin this isn't going to work.

 

[funky]

If you what to make things complicated (but maybe it isn't), you could use a named pipe, example:

mkfifo my_pipe
while true ; do cat my_pipe ; done

Then do something like this in another shell:

echo "print this to my_pipe" > my_pipe
echo "then it will show up on the other terminal" > my_pipe

If you don't need the named pipe anymore you can remove it like a normal file. But note that each cat command is blocked until something is written to my_pipe. The same holds for launching the first echo command before launching the first cat command, the echo will block until some process reads from my_pipe.

 

[batonsu]

Thanks Funky, and everyone. Named pipes seem exactly what I was looking for! Still don't fully understand how it works though. I did this:

$ mkfifo in
$ nohup cat < in &

It succsessfully executed in background, awaiting input from 'in'. But when I tried to echo into 'in', here's what I got:

$ echo 'text' > in
$ appending output to nohup.out
text2
-bash: text2: command not found
[1]+  Done                    nohup cat < in
$ cat nohup.out
text

Cat worked nice, but I don't understand why I got that message on the 2nd line, and why on the 3rd line there was bash awaiting for input from my keyboard!

 

[funky]

Cat worked nice, but I don't understand why I got that message on the 2nd line, and why on the 3rd line there was bash awaiting for input from my keyboard!

bash was not waiting for user input, it was just that the output of nohup included a line-break. You won't get that output if you redirect it yourself:

nohup cat < in > out.txt 2> err.txt &

 

[batonsu]

Thanks a lot, Funky! Looks like it works.

 

[batonsu]

$ nohup [I]program[/I] < [I]named_pipe[/I] >> out.txt &
$ echo 'command' > [I]named_pipe[/I] [I][B](works)[/B][/I]
$ echo 'command' > [I]named_pipe[/I] [I][B](doesn't work)[/B][/I]

Not that good as I thought... My program waits for the input from a named pipe, but once it gets the input, the program no longer takes care about the pipe. In other words, only the first line written into the pipe is read by the program.

Remember, when I launch the program in the console, it always waits for the input. I just wish it do the same with the pipe, just like with the keyboard =(

 

[funky]

Your program has to work like the simple "while true ; do cat my_pipe ; done" example program from above. At each iteration it waits for input to my_pipe, if there is some input it gets processed, then it goes on with the next iteration and again waits for some input. But as I said in my second post, this might get complicated. So rather use a terminal multiplexer (tmux, screen) as simple solution for now. Then you can hack in the background the cool pipe solution .

 

[batonsu]

Your program has to work like the simple "while true ; do cat my_pipe ; done" example program from above.

When I launch my program in a console, it constantly waits for the input from keyboard, until you enter the 'stop' command, or kill the process. So I guess, it's exactly the "while true ; do cat stdin ; done" type of program.

But looks like the pipe acts different to the keyboard device file: system just reads the pipe once into argc, argv and launches the program.

But where is the program's stdin then during runtime? It's kinda rhetorical question, but I will find the truth! )