Reputation
Top tag
Next privilege 200 Rep.
See reduced ads
Badges
12
Newest
 Excavator
Impact
~6k people reached

May
29
comment How to limit CPU consumtion of a process group with standard GNU/Linux tools?
… And if nothing else is using CPU time, they still are gobbling up all the 100%. But mentioning nice in this context surely is worth the effort.
May
29
comment How to limit CPU consumtion of a process group with standard GNU/Linux tools?
Processes sometimes react weirdly if stopped and continued. Especially if they are terminal-interactive. So this might not work with every program, and a corresponding warning should be included in the answer.
Feb
23
comment Monitoring a file until a string is found
As I wrote: With this solution the tail runs one line longer than necessary (without halting termination of the grep and thus the main command) and at least in my cases this is not a problem. I'm hard pressed to think of a scenario in which this is more than an academic issue.
Feb
23
comment bash Segfault by infinite recursion
Thank you @hastur, that was enlightening about the history of the "bug". The question remains whether this is a security issue. Probably too chaotic behaviour to exploit it, I guess.
Feb
19
asked bash Segfault by infinite recursion
Feb
18
comment Monitoring a file until a string is found
Actually, I now go for the even simpler grep -q -m 1 trigger <(tail -f log) proposed elsewhere and live with the fact that the tail runs one line longer in the background than it needs to.
Feb
17
awarded  Excavator
Feb
17
revised Monitoring a file until a string is found
took out wrong notion
Feb
17
awarded  Critic
Feb
17
comment Monitoring a file until a string is found
@ZaSter: The tail dies only at the next line. Try this: date > log; tail -f log | grep -m 1 trigger and then in another shell: echo trigger >> log and you will see the output trigger in the first shell, but no termination of the command. Then try: date >> log in the second shell and the command in the first shell will terminate. But sometimes this is too late; we want to terminate as soon as the trigger line appeared, not when the line after the trigger line is complete.
Feb
17
suggested approved edit on Monitoring a file until a string is found
Feb
17
comment Monitoring a file until a string is found
@mems, any additional line in the log file will do. The tail will read it, try to output it and then receive a SIGPIPE which will terminate it. So, in principle you are right; the tail might run indefinitely if nothing gets written to the log file ever again. In practice this might be a very neat solution for a lot of people.
Feb
17
comment Monitoring a file until a string is found
This polling has two main drawbacks: 1. It wastes computation time by going through the log again and again. Consider a /path/to/the.file which is 1.4GB large; then it is clear that this is a problem. 2. It waits longer than necessary when the log entry has appeared, in the worst case 10s.
Feb
17
comment Monitoring a file until a string is found
Another idea: Your fifo solution can be straightened, I think, by passing the output of the tail -f through the fifo and grepping on it: mkfifo f; tail -f log > f & tailpid=$! ; grep -m 1 trigger f; kill $tailpid; rm f.
Feb
17
comment Monitoring a file until a string is found
You solution (like others, I won't blame you) will miss things already written to the log file before your monitoring started. The tail -f will only output the last ten lines, and then all the following. To improve this, you can add the option -n 10000 to the tail so the last 10000 lines are given out as well.
Dec
17
awarded  Popular Question
Jul
2
comment Thunderbird Search Results — How to find out the folder
I had to switch to a "list of results" to go this way but then it worked just fine, thanks!
Jul
2
accepted Thunderbird Search Results — How to find out the folder
Jul
2
asked Thunderbird Search Results — How to find out the folder
Mar
7
awarded  Commentator