Tag Info

New answers tagged

0

Newer derivatives of the OpenBSD netcat, including FreeBSD[1] and Debian[2], support a -d flag which prevents reading from stdin and fixes the problem you described. The problem is that netcat is polling stdin as well as its "network" fd, and stdin is reopened from /dev/null in the second case above, where the shell function is run in the background before ...


1

Does the problem go away if you run the function like this? irc_notify </dev/null & If so, the problem is probably two processes simultaneously trying to read from stdin. Running all ssh commands with -n, like zackse suggested, might also help, at least to debug which processes are fighting over stdin. (I'd post this as a comment because it's ...


1

UPDATE: Given that find is the source of the data, I would use an array instead: readarray -t to_remove < <(find ...) number_of_files=${#toremove[@]} rm -i "${to_remove[@]}" If you are a pre-4 version of bash, use this loop to fill the array. while IFS= read -r fname; do to_remove+=("$fname") done < <(find ...) None of these work with ...


0

I figured it out. IFS=$'\n' for f in `echo "$to_remove"` ; do rm -ir "$f" done Short version: IFS=$'\n' rm -ir "$to_remove" Those two versions works as expected. Strange enough the following code doesn't work: IFS=$'\n' for f in "$to_remove" ; do rm -ir "$f" done Why?


1

In shells that support them (ksh, zsh, bash4), you can start program as a co-process. ksh: program > output |& zsh, bash: coproc program > output That starts program in background with its input redirected from a pipe. The other end of the pipe is open to the shell. Three benefits of that approach no extra process you can exit the script ...


2

On Linux, you can do: read x < /dev/fd/1 | program > output On Linux, opening /dev/fd/x where x is a file descriptor to the writing end of a pipe, gets you the reading end of the pipe, so here the same as on the stdin of program. So basically, read will never return, because the only thing that may write to that pipe is itself, and read doesn't ...


2

Here's another suggestion using standard Unix utilities, to "do nothing, indefinitely". sh -c 'kill -STOP $$' | program > output This fires up a shell that is immediately sent SIGSTOP, which suspends the process. This is used as "input" to your program. The complement of SIGSTOP is SIGCONT, i.e. if you know the shell has PID 12345 you can kill -CONT ...


1

You can create a binary that does just that with: $ echo 'int main(){ pause(); }' > pause.c; make pause


0

You can get rid off the message if you redirect std error to std output: nohup java -jar ./exhibitor-1.5.1/lib/exhibitor-1.5.1-jar-with-dependencies.jar -c file --fsconfigdir /opt/exhibitor/conf --hostname phx5qa01c.phx.qa.host.com > exhibitor.out 2>&1 &


0

This is what I came finally up with, thanks to the neat Perl command contributed by JJoao: # kill everything on termination trap "kill 0" SIGINT SIGTERM # Make sure the remote processes are killed on exit, see http://unix.stackexchange.com/questions/103699/kill-process-spawned-by-ssh-when-ssh-dies shopt -s huponexit ( while [ 1 -eq 1 ]; do ssh -t -t ...



Top 50 recent answers are included