We don't need to know the path of stdout. It doesn't even necessarily have one. The code suffers from the TOCTTOU mentioned in #244, and it also uses /proc (a Linux extension) on non-Linux systems, so it's possible to affect the behavior of scrot by creating a /proc/self/fd/1 file on non-Linux systems.
https://github.com/resurrecting-open-source-projects/scrot/blob/99be99fee14b6456aca84c6168e89817b050d64a/src/options.c#L339-L348
This is probably because the imlib APIs we use want an output filename instead of an output file descriptor which is a design bug in imlib because it creates more races and unnecessarily limits the usefulness of the library (can't pick whether or not to overwrite a file, for instance). I looked at the headers of Imlib 1.10.0 and there is no function that writes an image to a given fd.
Imlib has added a function to address this in 1.11.0 on scrot's request, we need to migrate to it.
We don't need to know the path of stdout. It doesn't even necessarily have one. The code suffers from the TOCTTOU mentioned in #244, and it also uses /proc (a Linux extension) on non-Linux systems, so it's possible to affect the behavior of scrot by creating a /proc/self/fd/1 file on non-Linux systems. https://github.com/resurrecting-open-source-projects/scrot/blob/99be99fee14b6456aca84c6168e89817b050d64a/src/options.c#L339-L348 This is probably because the imlib APIs we use want an output filename instead of an output file descriptor which is a design bug in imlib because it creates more races and unnecessarily limits the usefulness of the library (can't pick whether or not to overwrite a file, for instance). I looked at the headers of Imlib 1.10.0 and there is no function that writes an image to a given fd.
Imlib has added a function to address this in 1.11.0 on scrot's request, we need to migrate to it.