Piping to head results in broken pipe in shell script called from python

Question

I have a command I would to run to generate random string:

var=`< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c8`

When I run this command in interactive bash session I get absolutely no errors. But when I put this command into script and run it as a script I get Broken pipe error indicated by tr. I've read several related topics but still has no answer why script and interactive behavior is different and is there a way to control it with shell options or with something else?

Edit I:

In regards to comments given I found that indicating broken pipe errors can be controlled via:

 trap - SIGPIPE # to ignore errors

and

 trap "" SIGPIPE # to display errors

Edit II:

Well, I've provided incorrect information about reproduction conditions. Finally it seems that problem caused with the python wrapper that called the script with the os.system():

 python -c "import os; os.system('sh -c \"< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c8\"')"

Line given produces broken pipe errors independently of used OS.

Edit III:

This topic has been discussed here: https://mail.python.org/pipermail/python-dev/2005-September/056341.html

Answer 1

If one of the parent processes traps sigpipe , then the pipeline will inherit the ignore signal disposition, which will cause this problem you're experiencing.

This can be (safely) reproduced with:

( trap '' pipe; var=`< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c8 )

Normally, the head -c8 command will be done pretty soon at which point its stdin is closed. Since it's stdin is a pipe connected to the stdout of tr , it now no longer makes sense for tr to write to its stdout . Once it tries to, the system will kill it with SIGPIPE . Unless tr ignores this signal or has inherited the ignore ( SIG_IGN ) disposition for this signal from its parent. Then a write to tr 's broken stdout will simply cause a regular error and set errno to EPIPE at which point tr will most likely stringify and outputs this error to its stderr and exit.

Answer 2

This answer provides a good summary of the problem with piping from Python to head , and shows some workarounds.

https://stackoverflow.com/a/30091579/456550

Answer 3

The problem seems to be that head reads the specified (or default) number of lines from the input stream, prints them, and then quits. So an upstream program in a pipe that is still writing finds the output stream closed. In my opinion, this is a limitation in the design of head itself. You can instead use sed , which reads the whole stream: sed -n "1,10p" is equivalent to head -n10 .