Hacker News Reader

Comment by mateuszf | Hacker News Reader

Nice here document feature I have found recently is heredoc with pipe, e.g.

  cat <<REQUEST_BODY |      
  {
    "from" : 0,
    "size" : 40
  }
  REQUEST_BODY
  curl http://localhost -d @-

It allows to pass heredoc text to standard input of next command.

View on HN

This is a prime example of useless use of cat. Heredoc already means "pass this as stdin", there's no need to pipe it. Your example without cat:

    curl http://localhost -d @- <<REQUEST_BODY
    {
      "from" : 0,
      "size" : 40
    }
    REQUEST_BODY

Well, maybe in that case it is. But I like to separate the commands so that the data flow looks sequential. That way it makes more sense to me.

Much as I hate the cargocult invocation of "UUOC", this is actually nicer because it reads more sanely - the HEREDOC is properly linked to the curl whereas the previous has the curl seemingly adrift on its own line unattached to the HEREDOC.

I like modularity:

    request_body() {
        cat <<REQUEST_BODY |      
        {
            "from" : 0,
            "size" : 40
        }
        REQUEST_BODY
    }

    get_url() {
        curl http://localhost -d @-
    }

    request_body | get_url

I find it helps readability when you come back to it a year later. Of course, it's also easy to parameterize the body, if needed.

/readability sometimes trumps YAGNI

My issue with this is that unless you're maintaining a lot of context and understanding the precise weirdness of HEREDOC piping, that looks at first glance like you're catting the HEREDOC to STDOUT and then running a random curl command. It's clever, sure, but it's harder to read and maintain.

You can also write curl after the pipe

    cat <<REQUEST_BODY | curl http://localhost -d @-
      {
        "from" : 0,
        "size" : 40
      }
    REQUEST_BODY

Reply on news.ycombinator.com