Hacker News Reader

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

  % wc -l foo
  1310720 foo
  % cat foo | cat | cat > foo
  % wc -l foo
  16384 1

I always get confused between "tac" and "rev", which is also "cat, but backwards" for a certain definition of "backwards".

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

http://www.nicemice.net/par/ (or apt-get install par)

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.

    export CDPATH=.:~/projects
    export PS1="$(uname -n)$ "
    alias ltr='ls -ltr'

More of a procedure, always list file and edit the command before deleting it:

    $ ll file.txt
    -rw-r--r--  1 zera  staff  0 Jan  7 20:28 file.txt
    Ctrl-p, Ctrl-a, Ctrl-d, Ctrl-d, r,m
    $ rm file.txt

So this is a sanity check to avoid this mistake:

    $ rm *.txt

*Edit, one more:

Ensure you overwrite a file (or aren't):

    $ cp -i ~/file.config /etc/

    alias lsd="ls -ltrF | grep ^d"

Helps me quickly list only directories. Any better alternatives ?

Using `find` is nice to get just directories:

$ find . -type d -maxdepth 1

I use:

% ls -d */

ls -al | grep ^d

(Fails if a directory has a linefeed in its name followed by a 'd'. :-)

  find . -type d

edit: for the same output as your command you can use:

  dir -l

Dunno what "better" means, but this also works:

find -maxdepth 1 -type d

seconded. what I have always used

Depends on the shell. In zsh (with EXTENDED_GLOB): *(/) matches only directories.

I usually

    alias lsd='ls -d */'

ls -l | grep drw

I know, it's a bad habit

echo */ (perfect when your unable to fork)

sl

alias emacs="nano"

export EDITOR=/usr/bin/nano

nooooooo!

tsort. It's pointless until you need it, but when you need it, it's totally awesome.

less. Overkill, but SO MUCH BETTER THAN tail -f. Seriously. You can toggle "follow mode" without losing your place in the incoming stream.

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

I prefer:-

    tail --follow=filename

to:

    tail -f filename

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.

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

[1] http://www.vanheusden.com/multitail/features.php

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.

Hm, can you start at the end of file without reading the entire file with less? Use case is tailing large logs.

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.

Yes. It is CPU intensive (see auntie post above).

dtrace :P

Reply on news.ycombinator.com