On 2022-04-25 at 10:40 -0400, Chet Ramey wrote: > > > Perhaps BASH_COMPAT=5.0 could be extended to handle this. > > > > I think a shopt makes more sense. Forcing heredocs to be files > > although something legit to request, is more a caller workaround to > > bugs in called programs. > > Shell options aren't intended to cater to broken programs; that's > what the compatibility mode is for. > > It's not `legit to request'; the only thing guaranteed is that the > user will get a file descriptor they can read from.
This response originally surprised me, but you have a point. The interface is just a fd, and usage of a file an implementation detail. Still, based on what surfaced on this thread, one might argue the need for a *seekable* fd, in which case we end up in a pretty similar situation. A seekable fd could be made with Linux-specific memfd_create(), maybe worth considering. Some systems might also create seekable fds with POSIX shm_open(), but read()ing them isn't even defined, so not worth considering. I see a pattern there where a heredoc is converted to a fd (pipe/file), then the fd is (often) made into a bash buffered input. I think that going directly from heredoc to the buffered input would allow avoiding the temporary file/pipe altogether, and the penalty associated with 1- byte reads in the case where it is not going to a separate program. That probably requires some refactoring to work out though. Kind regards PS: Looking at the use_tempfile branch (actually the part fulfilled by sh_mktmpfd), that could benefit from O_TMPFILE | O_EXCL on modern Linux kernels.
