Very short summary:cat $file | patch produces a Bad file descriptor-error, butpatch < $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 [1] (and extracted the archive, of course).I want to patch it with TuxOnIce as downloaded von [2], 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-runpatch: **** can't open file Documentation/kernel-parameters.txt : Bad file descriptor(exitcode: 2)but:$ patch -p1 --dry-run < ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch checking file Documentation/kernel-parameters.txtchecking file Documentation/power/tuxonice-internals.txt[...](runs successfully).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. [3]If I export LD_PRELOAD='' or 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_PRELOAD itself, since when I export LD_PRELOAD='/usr/lib/libgtk3-nocsd.so.0' (the file exists) the patching with cat $file | patch works.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 xzcat or bzcat on the compressed patch files so that I don't need to decompress them in an extra step first.I use 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 strace, once strace-ing cat, once strace-ing patch, with export LD_PRELOAD=/usr/lib/libtrash.so and export TRASH_OFF=YES:Command:$ strace cat ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch | patch -p1 --dry-runOutput:http://pastebin.com/TD81znz6Command:$ cat ../patches/tuxonice-for-linux-3.18.21-2015-09-08.patch | strace patch -p1 --dry-runOutput:http://pastebin.com/snvN3YCu(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 patch.[1] linux kernel: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.21.tar.xz[2] TuxOnIce: http://tuxonice.nigelcunningham.com.au/downloads/all/tuxonice-for-linux-3.18.21-2015-09-08.patch.bz2[3] libtrash: http://pages.stern.nyu.edu/~marriaga/software/libtrash/
patch: bad file descriptor in combination with pipe and LD_PRELOAD/ libtrash
pipe;io redirection;dynamic linking;stdin;patch
libtrash is broken:For example, in helpers.c:char* make_absolute_path_from_dirfd_relpath(int dirfd, const char *arg_pathname){   char *abs_path = NULL;   if (arg_pathname == NULL)     {    return NULL;     }   else if (arg_pathname[0] == '/' || dirfd == AT_FDCWD)     {    return arg_pathname;     }   else if (dirfd <= 0)     {    errno = EBADF;    return NULL;     }A value of 0 for a file descriptor is perfectly legitimate.  Since you're using redirection, you're reading from stdin, which is file descriptor 0.  I suspect that's what's breaking somewhere in libtrash.