Tag Info

New answers tagged

6

The pipe will immediately get closed on nc's end. When omxplayer dies nc will receive SIGPIPE on writing to the fifo, not to the pipe. It might be better to just run nc in the background so that you could keep control over omxplayer via stdin. mkfifo tcp.stream nc -l -p 1234 > tcp.stream & omxplayer --live tcp.stream However, using | instead of ...


4

The "problem" is, that gpg writes directly to the TTY instead of STDOUT or STDERR. That means it cannot be redirected. You can either use the --batch option as daniel suggested, but as a more general approach you can use the script tool, which fakes a TTY. Any output is then sent to STDOUT, so you can redirect it to /dev/null: script -c 'echo ...


4

Add the --batch option. If you would like to achieve the same result through redirection you would have to close STDIN through: gpg … <&-


2

That's the effect of MULTIOS. echo foo >&2 | grep foo will write foo to stderr and also pipe foo to grep. Because stderr defaults to terminal, you will see two foo lines, one from echo, one from the grep result. { echo foo >&2 | grep foo } >/dev/null Here, you saw one line because stdout was redirected to /dev/null, you only saw the ...


1

I personally prefer using less to do this same thing. less your_file After starting less, the F command (not a command line flag) will begin to actively monitor the end of the file. While watching the end of the file in this mode CTRL-c will stop appending output to less and allow you to page around. Very handy.


3

I see two options. One, he can use tail -f to see the log file as it's being written, or two, he can have the program start inside a screen (or similar) session to which he can (re-)attach later. If he doesn't know the location of the log file, he can use top, ps or a similar tool to find the process ID, then run lsof -p1234 where 1234 is the process id to ...


2

Does your setopt output mention noclobber? If so, that's it, just setopt clobber


3

Because rm -i expects user's input from stdin, too. Try this: echo "$MOUNTPOINTLIST" | while read onelineforrm; do rm -i "${onelineforrm}testfileforwrite" < /dev/tty; done


1

Damn, just after I posted my question I figured out the problem (after trying to find an answer for about an hour or two). It would seem that tarsnapper just outputs all of its normal output to stderr instead of stdout. I think this is a bug in tarsnapper. But to answer my own question I just need to redirect using 2>/dev/null instead (to rediredt ...


2

sort can take multiple input files (and has a built-in uniq equivalent -u). Combine that with a fancy bash process substitution to result in: sort -u <(tshark -r sample.pcap -T fields -e eth.src -e ip.src) <(tshark -r sample.pcap -T fields -e eth.dst -e ip.dst) > hello_uniq


2

(tshark -r sample.pcap -T fields -e eth.src -e ip.src; tshark -r sample.pcap -T fields -e eth.dst -e ip.dst) | sort | uniq > hello_uniq


1

According to man time you should be able to use -o FILE to output to a file and -a to append to the file. So your command should be: /usr/bin/time -a -o log.txt python script.py >> log.txt Using the -f flag you can set the desired output format of the times.


2

For every shell function I write I do this exact same thing. fn(){ echo some normal stderr debug stuff >&2 #if $DBG 2>stderr dd if="\$DBG/please/report/on/this/file" #ditto echo I DEFINITELY need to handle this >&3 #always stderr ( PATH=; ".some" oops I expect to handle ) ...


3

For such a purpose I usually define a function like run. This can correctly handle args with spaces and others in most cases. #!/bin/bash run() { if $DEBUG; then v=$(exec 2>&1 && set -x && set -- "$@") echo "#${v#*--}" "$@" else "$@" >/dev/null ...


2

perhaps you could use a function to pipe the output to and let it do the redirection: #! /bin/bash DEBUGMODE="Debug" function handleStdOut { if [[ "$DEBUGMODE" == "Debug" ]] then echo "Debugging..." cat echo "Done" else cat > /dev/null fi } echo "bla" | handleStdOut


2

In your case echo is treating $REDIR as a string argument. You want something like: ~$ echo "bla" >/dev/null 2>&1 ~$ REDIR='>/dev/null 2>&1' ~$ eval "echo bla $REDIR" ~$ However, unless you are trying to do a quick and dirty hack, Wouter Verhelst has the better solution (and it's really not that long or complicated).


6

Redirection is not a command, therefore you can't execute it in this manner. You can get it done if you use eval, but that's opening a can of worms. A better method to do what you're trying to do is have a function for debugging output: function debugprint { if [ ! -z "$debug" ]; then echo "$1" fi } debugprint "$(echo 'bla' 2>&1)" ...


3

Make the target log file a named pipe, with your filtering script on the other side.


1

People usually do this with tee: cmd | sudo tee /long/path/x.{load,conf} tee writes copies of its input to all of its named output files - and in the same way the redirection occurs before an exec so also does the argument generation in brace expansion. So the above should work fine and write to both resulting file names at once and the standard out. If ...


2

Awk's redirection operator comes in handy here. Here are a few variations on this theme. cmd | sudo awk '{print >"/long/path/x." (NR==1 ? "load" : "conf")}' cmd | sudo x=/long/path/x awk 'NR==1 {print >ENVIRON["x"]".load"} NR==2 {print >ENVIRON["x"]".conf"}' cmd | sudo awk 'FNR==1 && NR!=1 {exit} {print ...



Top 50 recent answers are included