"cat foo > foo" breaks, because the shell truncates the file "foo" while it's setting up the redirection, before it launches "cat foo", and so cat has nothing to read.
"cat foo | sponge foo" works because the shell is not responsible for writing to foo; it launches cat (which opens the file for reading) then launches sponge (which eventually opens the file for writing).
I would thus expect "cat foo | tac | tac > foo" to fail in the same way as "cat foo > foo" because the shell is still going to open the file foo and truncate it, but experimentation shows that it does actually work. Is it because the shell launches each pipeline one at a time, so cat has read the file before "tac > foo" truncates it? Is it a race-condition or a corner-case?
That's a good question. I had though it worked because the truncate would not actually happen until tac actually wrote something, but now that I look at it more I don't think that is actually the case. `cat > foo` immediately truncates foo before anything is written. Also `tac foo > foo` doesn't work, which discredits my hypothesis that tac's buffering was causing it.
Furthermore `cat foo | cat > foo` does not work, but `cat foo | cat | cat > foo` does work.
I suspect this behavior is actually a race condition of some sort.
Edit: definetly a race condition, shown by larger files:
When rewriting large amounts of ASCII text (or comments in Code), I really find "par" helpful.
: Just use it in :
: vi with your cursor in front of a badly wrapped block of text. :
: Press !}par<enter> and the text will be :
: piped to par :
: which fixes up :
: the :
: formatting and keeps aligned frame markers :
: intact magically. :
: Just use it in vi with your cursor in front of a badly wrapped :
: block of text. Press !}par<enter> and the text will be piped :
: to par which fixes up the formatting and keeps aligned frame :
: markers intact magically. :
Or you can just select the block of text and type gq. This will do what par does, and can be adjusted with vim's 'textwidth' and 'formatoptions' settings.
> less. Overkill, but SO MUCH BETTER THAN tail -f. Seriously.
If you do this on my servers, I am going to find you, and then I am going to kill... um... your process.
less with SHIFT-F takes a whole CPU core to run on a busy log file. tail -f takes almost nothing to run. Now combine that information with the reality of a whole bunch of devs who don't know it or don't care about it. :(
The former will spot inode changes and reopen the filename if the file wraps (or has something else done to it to change its inode). The latter will just sit there seeing no new input in such cases.
Yes, either type G when presented with the top of the file or pass +G on the command line. It will then read all the intervening file to calculate the line numbers, and tells you it's doing this and to interrupt it to stop. To prevent it doing this in the first place use the -n option.
"less -n huge_file" and then G only reads the start and end of the file. Type G again to move to the latest end of the file if it's growing.
multitail[1] is also really nice for following multiple log files. It can do highlighting of lines based on regex's, and has built-in highlighting of a wide variety of log formats
Does anybody know if there is a good standalone regex highlighter? I usually use `ack --passthru`, but that has always seemed a tad.. overkillish to me.
