4 ms·
Nice here document feature I have found recently is heredoc with pipe, e.g. cat <<REQUEST_BODY | { "from" : 0, "size" : 40 } REQUEST_BODY
by mateuszf 13y ago
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.
- lotheac 13y agoThis 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
- mateuszf 13y agoWell, 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.
- zimpenfish 13y agoMuch 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.
- pdkl95 13y agoI 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
- zimpenfish 13y agoMy 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.
- mhitza 13y agoYou can also write curl after the pipe cat <<REQUEST_BODY | curl http://localhost -d @- { "from" : 0, "size" : 40 } REQUEST_BODY