Tag Info

New answers tagged

0

From your experiments, it appears that the vsim program wants its standard input to be connected to a terminal; if it isn't, it either does nothing useful (because it's waiting for input but not getting any) or exits. $ vsim $ sh -c vsim This runs the command normally from a terminal, in the foreground. The command can read input from the terminal. $ ...


4

I you mean that someone may open 2 TCP connections to your machine, one to port 50505 and another to port 60606, send data on the first one intended to be fed to P and expect to read the output of P from the second TCP connection, then that would be: < /dev/null nc -q -1 -l 50505 | P | nc -l 60606 > /dev/null Or with socat: socat -u ...


-1

You don't need nc in order to work with ports. bash can do that itself: Bash handles several filenames specially when they are used in redirections, as described in the following table: /dev/fd/fd If fd is a valid integer, file descriptor fd is duplicated. /dev/stdin File descriptor 0 is duplicated. /dev/stdout File descriptor 1 is ...


1

Yes, in version 0.8, you can use -infile as in pocketsphinx_continuous -infile /dev/stdin. The documentation is still trying to catch up with this new feature!


2

If you want to read from standard input twice, you need to buffer it somehow (most likely, in a temporary file). The first cat can be replaced by a call to tee which also writes the data to a file, which can be reread by the second call to cat (which is not necessary either; sed can read from the file directly). tee > input_buffer # Copy standard input ...


5

You are doing nothing wrong: this is what we should expect. The first cat <&0 consumes the entire contents of standard input because that's what cat does: it reads all of its input until the end. When the second cat <&0 runs, there is nothing left to consume on standard input: the end of file was already reached previously. If, in a shell ...



Top 50 recent answers are included