Tag Info

Hot answers tagged

16

The simplest solution is to combine the two echo commands. echo $'y\nresponse' | ./command.pl Writing a string with single quotes and a $ in front tells bash to interpret escape sequences like \n. If the commands you were piping were more complicated, you could group them with curly braces. { echo y; echo response; } | ./command.pl Parentheses would ...


7

Have you tried grouping your two answers in a single echo separated by a newline? echo -e "response\ny" | ./command.pl Note the -e flag is necessary with bash to enable interpretation of backslash escapes (unless bash is in Unix conformance mode). Or more portably: echo 'response y' | ./command.pl Or: printf 'response\ny\n' | ./command.pl Or: ...


6

In: ... | xargs cmd depending on the implementation, cmd's stdin is either /dev/null or that pipe. It cannot be the outer stdin since that is lost because of the piping. $ echo /proc/self/fd/0 | gnu-xargs ls -ld lr-x------ 1 me me 64 Dec 11 22:04 /proc/self/fd/0 -> /dev/null $ echo /proc/self/fd/0 | busybox-or-solaris-...-xargs ls -ld lr-x------ 1 ...


5

You can also use a here document: ./command.pl <<END response y END


4

I put the commands into a file then catted the file into the command and that worked. cat blah.txt | ./command When I came back, I noticed user43791's response, so will accept that as the answer which looks to be the same thing I did, but more succinct.


4

Digging around here, I understood from http://unix.stackexchange.com/a/56877/54067 (where both the question and answer are worded differently and the problem is not related to interactive input) that the reason for the problem is that the cp -i expects the user to give the interactive input confirmation via stdin but in the cat | while read loop stdin is ...


4

When you do: nohup echo "45" > my_named_pipe & The shell forks itself. In the child, it opens my_named_pipe for writing. That open() blocks until something else opens my_named_pipe for reading. When you run exit in the parent process, the child is still blocked on the open() and has not executed nohup yet. So upon exiting you shell, the shell ...


4

Yes, that's a race condition. The problem is that the shell starts all processes in the pipeline at the same time and tee truncates the output file on startup. If tee is faster then comm the file is empty for comm otherwise it is not. The pipeline behaviour can be seen if you run this several times (mabe in a loop): date '+first: ...


3

Each part of pipelines run in separated processes, or own subshell. So when your pipelines finished, your current shell does not know anything about function f. With bash (ksh, pdksh, zsh, mksh or shell that support Here-String), your can use: $ source /dev/stdin <<<'f() { echo a; }' $ f a POSIXly, you should use Here-Document and dot: $ . ...


2

The problem you're having, and the reason it's shell-dependent, is that the > redirection is processed first, and if nobody is reading the pipe yet, it will block. Only after the open succeeds will the shell execute nohup. You disconnected while it was still blocked in open, so nohup hadn't happened yet and the SIGHUP killed the background process. This ...


2

You can do something like: func > >(tee log.txt) 2>&1 wait You can dedicate a file descriptor for logging: exec 3> >(tee log.txt) tee_pid=$! func >&3 2>&1 ... Beware though that as that tee runs in background, if not all the output goes through it, then the order in the output may be affected.


2

The commands in a pipe are separate processes, hence the function definition that is sourced from /dev/stdin is lost as soon as the pipe completes. That is why the pipe show different results to the usage of the temporary file. In your use case the eval as suggested by PM 2Ring would be the way to go.


1

You can use process substitution source /dev/stdin < <(echo -ne 'f() { echo a; }\n') or source <(echo -ne 'f() { echo a; }\n') This works in bash 4.1.5, for some reason it doesn't work in 3.2.48.


1

You suffer from pipe buffering. Usually output to non interactive terminal is buffered to 4Kb blocks until delivered via pipe, so you have to disable it. You could alter your command line like this: $ stdbuf -oL ping 10.1.10.28 | perl -ne '$|=1; /time=(\d+\.\d+)/ && print "$1\n"' > file stdbuf is part of coreutils. $|=1; is the way to ...


1

The command that made it work is: sudo stdbuf -i0 -o0 -e0 hostapd /etc/hostapd/hostapd.conf | tee log.txt


1

You can use xargs to feed the output of a command as arguments to another: find . -iname '*.txt' -print0 | xargs -0 tar zcvf the_tarball.tar.gz Note here the -print0 from find and -0 from xargs work in conjunction to delimit file names correctly (so that names with spaces and such aren't a problem).



Only top voted, non community-wiki answers of a minimum length are eligible