Tag Info

New answers tagged

1

Functions are perfectly suitable for this purpose. For example: cmd() { echo $* >> /path/to/file'; } This is on one line, just like an alias. But it can take parameters.


0

I would do like... #!/bin/sh -x run() if ! ps -p "$run" >&2 then n=0 run=$$ exec "$0" "$@" 2>&1 | { ! tee outfile ; } fi 2>/dev/null run "$@" || exit fn() { var=val$n; echo "$((n+=1)): $var"; } fn sleep 5 fn IN That first checks if it's already got an open pipe to a tee in another process, and, if not, it execs ...


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.


0

You can use a tmp file func >tmpfile 2>&1 tee 'log.txt' <tmpfile or a FIFO mkfifo pipe_replacement tee 'log.txt' <pipe_replacement & func >pipe_replacement 2>&1


0

Your line confused me a bit as it was not clear what both occurrences of "test" are supposed to be. - Therefore I really understand that your shell is confused, too. ;) If I understand correctly the first "/tmp/test" should correspond with the old output of the command and the second one corresponds with the new output. You can be sure that stdin will ...


5

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: $ . ...


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.


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.


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 ...


1

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


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 ...


5

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


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 ...


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.


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: ...


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).


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 ...


0

I'm not sure I'd call it an "answer" per se, but I was able to approximate what I was looking to do in a completely different way. Instead of nc, I've managed to get further along using a file descriptor on /dev/tcp. exec 3<>/dev/tcp/${host}/${port} echo -e "read?" >&3 cat <&3 | tee -a ${log} exec 3<&- exec 3>&- There are ...



Top 50 recent answers are included