bug#48940: 27.2; regression: "emacs --script /dev/stdin" parses the script incorrectly when /dev/stdin is a pipe

["Bryan C. Mills" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On Thu, Nov 11, 2021 at 12:09 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> "Bryan C. Mills" <bcmills@google.com> writes:
>
> > I tested the fix locally with a small dummy script as input and it
> > seems to work, but I can't be confident that there won't be deeper
> > bugs. You're welcome to use it as a starting point for a more robust
> > fix.
>
> I tried (on Debian/bullseye with Emacs 29), but it doesn't seem to make
> any difference here.  With or without the patch, I get:
>
> larsi@xo:~/src/emacs/trunk$ emake; cat /tmp/script.el | ./src/emacs -Q --script /dev/stdin
> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "/proc/162231/fd/pipe:[1065564]")
>   load("/proc/162231/fd/pipe:[1065564]" nil t t)
>   command-line-1(("-scriptload" "/dev/stdin"))
>   command-line()
>   normal-top-level()
>
> Perhaps something further has changed in the meantime?  (You didn't post
> an output of the error message you were getting...)

I did post the complete output: the pipeline `cat script.el | emacs
--no-init-file --no-site-file --script /dev/stdin` did not produce any
output whatsoever for my reproducer. (Nothing to stdout, nothing to
stderr.)

Since the return-value from lseek was ignored prior to my patch, the
failing seek did not necessarily lead to a diagnosed error at all — it
could instead result in a spurious EOF on the next read, or a parse
error from unintentionally continuing to read the file at the
unmodified (pre-lseek) offset.

I don't know what else may have regressed between when I mailed the
patch and when you looked at it in Emacs 29, and unfortunately I don't
have the time to look into it at the moment.