Useful use of cat(1)

2009-02-26 (see recent changes)

• embedded cat

    ( cmd; cat file; cmd ) | cmd 

  This was for example useful for me on a Redhat Linux, where man(1) otherwise annoyingly
  would intersperse the output with headers and footers for the - almost never used - print version.
  I tried: ( echo -e ".pl 1100i"; cat "$1"; echo ".pl \\n(nlu+10\n" ) | tbl | nroff -man

• create text files without editor

    cat > textfile

  then typing plain text and closing with EOF (aka <ctrl-d>) was the quickest way for me to create text files on systems running in some rescue mode.

• ...related: redirect to a file, if there was no command:

    tar cf - . | ssh remotehost 'cat > big.tar'

• actual concatenation, e.g., the opposite to split(1)

    cat xa* > c

  ...very related: a filter only reads from STDIN and you want to hand over several arguments.
  A redirection doesn't allow this. Examples: using tr, or converting tai64-timestamps in qmail-logs:

      cat log1 log2 log3 | tr '[:upper:]' '[:lower:]'
      cat log1 log2 log3 | tai64nlocal 

  ...related: falling back to STDIN if no arguments were supplied:
  (Chris F.A. Johnson, Richard L. Hamilton in c.u.s)

    cat ${1+"$@"} | cmd 

  Footnote to the last example: if arguments with leading dashes are possible,
  then inserting "--" (end of options) after "cat" helps. It's not strictly portable.
  The expression after cat links to a page explaining it.

• easy "intuitive" switching on the command line between different types input
  Let's assume you are writing and debugging a new filter command.
  Imagine switching between these two variants several times:

      cat known_data | new_filter | ...
             command | new_filter | ...

  and compare with these (avoiding the cat):

      new_filter < known_data | ...
      command    | new_filter | ...

  Alternatively, you can put the redirection at the left side (but only with simple commands, not with compound commands like loops, grouped lists and subshells)

      < known_data new_filter | ...
      command    | new_filter | ...

  On contrast to the other items, this is only a matter of taste.
  But I frequently use the first variant with cat exactly for reasons of convenience.

• here documents (force as-is output, if there are character sequences which are special to echo(1), and if printf(1) is not available)

    cat<<EOF          cat<<EOF|cmd
    $VARIABLE         $VARIABLE
    EOF               EOF 

  Be careful if you put the above into a function:
  Traditional bourne shells and ksh up to 88g can have
  problems with the handling of the temporary files for storing the here-document.

  (Reminder from Janis Papanagnou for how to embed a here-doc in a pipeline added, for those who haven't seen it, yet)

• convert file content into arguments

    cmd `cat file`
    for i in `cat file`; do ...

  However, don't forget about possible problems with characters from IFS, most likely spaces.

  Janis Papanagnou reminds that a non-portable (even non-standard) way without cat,
  supported by some modern shells is

    cmd $(< file ) 

• largefile problems (Darren Dunham in c.u.s)

    cat file | cmd 

  A workaround for commands which have been compiled without largefile support but accept a pipe, e.g. compressing utilities.
  This is not purely academic; it rarely occured, especially in the transition period to well established large file support (for example gzip-1.2.4).

• ...related: select()

  select can be applied to pipes, sockets and ttys but not to regular files.
  A program pathologically using select could be used again. (academic, but well spotted by Dan Mercer in comp.unix.programmer)

• eliminate pager functionality, pagers (like more(1)/less(1)/pg(1)) usually test stdout/stderr for an interactive TTY,
  and also a simple way to force ps(1) to print long lines (complete arguments)

    script_or_command | cat

• empty filter (probably academic but a nice orthogonal example)

    case x in
     a) filter=cmd;;
     b) filter=cat;;
    esac 

• ...related: pipeline status.

  If the last command in a pipeline would return an undesirable exit status, force the pipeline to return success with

    cmd1 | cmd2 | cat

  while an alternative is "{ cmd1 | cmd2 || true; }"

• Using flags of cat(1), e.g.

    cat -v 

  However, this is controversial from the viewpoint of the unix tradition "do one thing and do it well".
  See the paper "Program Design in the Unix Environment" by Rob Pike and Brian Kernighan for a rant about this.