Good, but not sufficient. Input may come from a pipe or a file, so you also should check STDOUT. But even that is not sufficient, because STDOUT could be redirected or piped, too, so you may also want to check STDERR. And, you may already have guessed that, even that is not sufficient, as also STDERR can be piped or redirected.
If you have a dual-mode script that can work both as a daemon ("background process") and as an interactive command, use a command line switch for the daemon mode. Make the daemon starter (daemontools, init, srvany.exe) pass that switch to your command. Alternatively, use a symbolic link and decide based on $0, or use two scripts that have their shared code in one or more modules.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l] |
It was my impression that with "in the foreground" the OP actually meant "interactively". And it's a matter of definition whether a process with stdin redirected (or std* for that matter) is still considered interactive.
Maybe the OP himself should clarify...
| [reply] |
Right. Given a windowed environment, one could also consider a process to be "running in the foreground" if it runs (in) the topmost window or the window that currently gets user input (from keyboard and pointing device). All other processes would be "running in the background". So, astroboy, please define "foreground" and "background".
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
