Question about bug in ksh

I've found follow开发者_StackOverflowing function in our old scripts:

f() {    # < files list
   typeset file
   cat - > $TMPFILE   # Bug in KSH
   while read -r file
   do
      process $file
   done < $TMPFILE
}

Does anyone know this bug in KSH?

Apparently f() is a filter function, i.e. you are supposed to use it in a pipe like so

./generate_filelist.sh | f

Where you'd expect read -r to read stdin just fine, e.g. when doing

./generate_filelist.sh | while read -r file; do echo $file; done

apparently, there is (was?) a bug in (certain) ksh (version(s)) that prevented the same to work from a function:

f() {
   typeset file
   while read -r file # whoops not reading from stdin as it should?
   do
      process $file
   done
}

I foun two bugs that could be it, depending mostly on your platform:

• flawed stream input optimization on MacOS
• alleged signal suppression in IllumOS (Open Solaris derivative)

There are possibly (many) more historical bugs that could apply, and I stopped searching because I don't know anything about your platform, or indeed the platform the script was designed for.

So instead there has been a workaround involving writing the stdin to a temporary file, and reading from that. Note that

• this changes semantics (reading starts after full file received only)
• there seems to be a typo ($$TMPFILE, probably instead of $TMPFILE?) in your sample (unless there is one more feature of KSH I wasn't aware of, $$ expands to the current process Id))

.

f() {
   typeset file
   cat - > $TMPFILE
   while read -r file
   do
      process $file
   done < $TMPFILE
}