Very short summary:
cat "$file" | patch produces a
Bad file descriptor-error, but
patch < "$file" works, when libtrash is preloaded with
LD_PRELOAD, and only on bigger projects.
Description: For this example, I work on the vanilla linux-3.18.21 kernel sources as downloaded from  (and extracted the archive, of course).
I want to patch it with TuxOnIce as downloaded von , and extracted.
In this example I show some big project, since with just small files everything works okay.
I work within the top level linux source directory, and from there the patch is located at
../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch. No symlinks involved, everything on the same filesystem.
The following happens:
$ cat ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch | patch -p1 --dry-run patch: **** can't open file Documentation/kernel-parameters.txt : Bad file descriptor
$ patch -p1 --dry-run < ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch checking file Documentation/kernel-parameters.txt checking file Documentation/power/tuxonice-internals.txt [...]
The problem has something to do with
libtrash.so loaded via the
LD_PRELOAD environment variable:
- By default, I have
export LD_PRELOAD=/usr/lib/libtrash.so. 
- If I
unset LD_PRELOAD, it works fine.
- If I just switch off the functioning of libtrash (but keep it preloaded), by
export TRASH_OFF=YES, which is the way provided by libtrash, the problems persist.
- It definitely has to do with libtrash and not with
LD_PRELOADitself, since when I
export LD_PRELOAD='/usr/lib/libgtk3-nocsd.so.0'(the file exists) the patching with
cat $file | patchworks.
In fact, I expect
cat "$file" | "$programme" to result in the same as
"$programme" < "$file", but it doesn't.
It's a practical nuisance, since in practice instead of using
cat, I would use things like
bzcat on the compressed patch files so that I don't need to decompress them in an extra step first.
bash, but that doesn't matter (within
zsh the same).
patch is GNU patch version 2.7.5,
glib-config --version shows 1.2.10, I use an arch linux distribution and this problem did persist already for at least several months, including updates. Kernel 3.18.21.
Here are two outputs with
export LD_PRELOAD=/usr/lib/libtrash.so and
$ strace cat ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch | patch -p1 --dry-run
$ cat ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch | strace patch -p1 --dry-run
(Sorry for linking it, if I would put it directly stackexchange won't accept my post without telling me why).
I am not familiar with dynamic linking,
strace and so on.
Does anyone know what goes on? If that is a bug somewhere, where would it be? (patch, libc, libtrash, dynamic linker, ..., ..., ?)
xzcat /usr/src/linux-3.18.21.tar.xz | tar -xv works (but
xzcat some.patch.xz | patch does not), so it has at least some specificity with
 linux kernel: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.21.tar.xz
 libtrash: http://pages.stern.nyu.edu/~marriaga/software/libtrash/