Red Hat 4.x to 5.x fuser "Enhancement"

I came across an interesting situation related to an upgrade of Red Hat.  Due to planned upgrades of Oracle 10g to 11g, we are first performing upgrades of RH from 4.x to 5.x.  Normally an OS upgrade would involve sanity checks that nothing breaks, but you'd expect your basic Unix commands to behave the same.

Yet after running a few DBA maintenance scripts I found a problem with one script that was using "fuser".  Our script checks a list of files to see if any are currently open and if so, it processes them differently.  The problem was that under RH 5.x (5.3, specifically), where "fuser" piped to "cut":

for active_file in `fuser $dir/$sub/* 2>&1 | cut -d\: -f1`

In the snipet of code above under RH 5.3, it appeared that both files and the PID from "fuser" were getting returned, as if "cut" didn't work at all.  After closer investigation it turned out that "fuser" was the guilty party.  I ran a simple test on a database server with Oracle running, knowing that "libclntsh*" would be open. 

Using the command:

fuser $ORACLE_HOME/lib/libclntsh* | cut -d\: -f1

… under RH 4 you'll get:

/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so

/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1

… while under RH 5 you'll get:

/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so:m

/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1:m

  7309  7309

I did a crazy thing and checked the "man" pages for "fuser" to see if I was missing something and sure enough, I was: a change in RH 5!  See the following line listed right before the OPTIONS section:

       fuser outputs only the PIDs to stdout, everything else is sent to stderr.

That explains the difference in behavior between releases.  Fortunately the workaround is easy: redirect stderr to stdout.

Fortunately I caught this, but I wonder what other changes are lurking out there?