Bug in :sh introduced at 8.2.1833

[Gary Johnson]

Starting with 8.2.1833, the :sh command no longer works when vim is
reading text from stdin. The screen flashes, but nothing else
happens.

To demonstrate this, execute the following:

$ ls | vim -N -u NONE -
:sh

Using git bisect, I found the offending commit.

$ git bisect bad
204ade6bcb85f48f56e52e040d1ebf40548d92be is the first bad commit
commit 204ade6bcb85f48f56e52e040d1ebf40548d92be
Author: Bram Moolenaar <Br...@vim.org>
Date: Sun Oct 11 14:58:46 2020 +0200

patch 8.2.1833: when reading from stdin dup() is called twice

Problem: When reading from stdin dup() is called twice.
Solution: Remove the dup() in main.c. (Ken Takata, closes #7110)

src/main.c | 15 +++++----------
src/version.c | 2 ++
2 files changed, 7 insertions(+), 10 deletions(-)

The operating system I'm using is Ubuntu 20.04.1 LTS.


More information:

If before executing :sh, you set the 'shell' to /bin/cat, then
executing :sh will cause cat to report the following error.

/bin/cat: -: Bad file descriptor
/bin/cat: closing standard input: Bad file descriptor

This problem also occurs when one of vim's arguments is a bash
process substitution. That's been a problem for a while.

My workaround is to detect the problematic conditions and then set
'shell' to a script containing the following.

#!/bin/bash
exec < /dev/tty
exec $SHELL "$@"

Regards,
Gary

[Bram Moolenaar]

I can reproduce the problem. I don't understand why it happens, the
close(0)/dup(2) in readfile() is executed. Somehow it needs to be done
again.

I'll remove the patch for now. Perhaps someone can debug why this is
needed.

--
It is illegal for anyone to give lighted cigars to dogs, cats, and other
domesticated animal kept as pets.
[real standing law in Illinois, United States of America]

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Gary Johnson]

I'm trying to look at this in the cracks, but the cracks aren't very
wide these days. I'm posting this for anyone else who might be
looking at this issue.

I was curious about the other, related bug in which

$vim -N -u NONE <(ls)
:sh

exhibits the same problem, that is, :sh immediately returns, and
thought I might learn something from that bug that helps fix them
both.

I found that the problem does not exist in an old version of vim,
7.2.330, I still had around. I did another git bisect search and
found:

$ git bisect bad
f71d7b9ee5ceba75f70c30845332ddd728fd16c6 is the first bad commit
commit f71d7b9ee5ceba75f70c30845332ddd728fd16c6
Author: Bram Moolenaar <Br...@vim.org>
Date: Tue Aug 9 22:14:05 2016 +0200

patch 7.4.2189
Problem: Cannot detect encoding in a fifo.
Solution: Extend the stdin way of detecting encoding to fifo. Add a test
for detecting encoding on stdin and fifo. (Ken Takata)

src/Makefile | 1 +
src/buffer.c | 130 ++++++++++++++++++++++++++------------
src/fileio.c | 14 ++--
src/testdir/Make_all.mak | 1 +
src/testdir/test_startup_utf8.vim | 64 +++++++++++++++++++
src/version.c | 2 +
src/vim.h | 3 +-
7 files changed, 168 insertions(+), 47 deletions(-)
create mode 100644 src/testdir/test_startup_utf8.vim

Regards,
Gary