In Bash 4.X It it possible to do something like:
command that expects input & echo some output | %1
Where %1 represents the first backgrounded command?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
Once you start:
rm -i -- * &
rm has been started with whatever stdin was in your shell at the time you invoked that command.
If it was the terminal, then
rm will typically be suspended (with the SIGTTIN signal) as soon as it tried to read from it (since it's not in the foreground process group of the terminal).
If you want it to read from something else, you have to tell it to reopen its file descriptor 0 on something else.
You could do that with a debugger (here assuming you're on Linux):
rm_pid=$! coproc yes gdb --pid="$rm_pid" --batch \ -ex "call close(0)" \ -ex "call open(\"/proc/$$/fd/$COPROC\", 0)" /bin/rm kill -s CONT "$rm_pid"
Above, we're starting
yes in background with its stdin and stdout redirected to a pipe. The other end of that pipe is in the shell (process
$$) on file descriptor
gdb, we're telling
rm to close its fd 0, and reopen it on that same pipe.
Yes, but you need a little bit more.
When you send a program to the background you're detaching it from
stdin associated with your terminal. You need to start it up instead with an alternate input, in this case a pipe.
$ mkfifo alternate_input $ command_that_expects_input < alternate_input
You've now assigned the pipe file (
alternate_input) as the
stdin for the process
command_that_expects_input. To send input, simply put something into the pipe.
$ echo foo > alternate_input
In this case the string
foo becomes is transferred to
The way you postulate, no. As terdon says, it's much easier if you know you need to pipe input in the first place. In the rare (so rare I've never encountered it) case where a program expects no input now but will expect input in the future, you can set up a named pipe as the input to that process, background it, then send output of a later-started process to the same named pipe, but you have to set the named pipe up beforehand.