Hi Brian,

I suddenly realized how the ^D issue in addbib can be fixed. I analyzed the structure of the original addbib program, and its backbone looks roughly like this:

use strict;

while (1) {
    print "Abstract: ";
    $_ = <>;
    next if (/^$/);
    print;
    while (<>) {
        print;
    }
}
continue {
    print "Continue? (y) ";
    $_ = <>;
    last if m/\A[nq]/i;
}

I found that the problem here is that once ^D is used inside the inner while loop, the entire standard input is closed. As a result, the $_ = <> in the continue block will never receive any valid input, because $_ will be undef. We can confirm this by testing it with defined.

The solution is to reopen standard input after exiting the inner while loop:

use strict;

while (1) {
    print "Abstract: ";
    $_ = <>;
    next if (/^$/);
    print;
    while (<>) {
        print;
    }
    if ( $^O eq 'MSWin32' ) {
        open STDIN, '<', 'CON' or die $!;
    }
    else {
        open STDIN, '<', '/dev/tty' or die $!;
    }
}
continue {
    print "Continue? (y) ";
    $_ = <>;
    last if m/\A[nq]/i;
}

With this change, <> can once again read from standard input, allowing the program to exit the outer loop as expected.

After adding the six new lines shown above to the old version of addbib, I found that it works very well. There is only one minor caveat: on Windows, standard input cannot be terminated using ^D; instead, it must be terminated using ^Z followed by <Enter>.

An advantage of this approach is that it avoids introducing Term::ReadKey as a dependency. However, I am not sure whether reopening standard input in this way is the best solution. It feels somewhat crude, but in practice it appears to work well on Windows, Cygwin, and Debian.