[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#728775: apt-get unwarrantedly consumes input



Steve Cotton wrote:
>It's to avoid someone typing their next command while packages are
>downloading, but then that input being used as the answer to a
>prompt during installation.

That can be used as an argument for all sorts of programs to clear stdin.
The Unix convention is that one does not.  For the purposes of this bug
report, I'm confident that the installation will not get interactive.
(I have debconf configured to non-interactive mode, which doesn't cover
all cases in which installation can get interactive, but does cover most.)

>There is an undocumented control flag DPkg::FlushSTDIN.

Setting that to "false" in /etc/apt/apt.conf.d doesn't make any practical
difference.

Looking at the source, I do see flushing cod controlled by that
flag, but it doesn't match the behaviour that I saw through strace.
It's in pkgDPkgPM::Go() in apt-pkg/deb/dpkgpm.cc.  Further down the
same function, there's a pselect loop which does match what I saw
with strace.  It reads from stdin conditional only upon (master >= 0 &&
!d->stdin_is_dev_null), not looking at configuration at all.  I expect
that both of these instances of stdin consumption need to be modified
for things to actually work as I want.

>But for your use-case of an interactive shell, wouldn't it be
>safer to just open another terminal?

Maybe; it depends on the circumstances.  (Again, it's an argument that
applies to all sorts of commands; apt-get is not a beautiful and unique
snowflake.)  Opening a fresh shell would avoid typeahead problems,
but would mean that the shells could differ in state such as current
directory, environment variables, and shell functions that I've just
written for the job at hand.  There's a risk of doing the wrong thing
simply due to failing to correctly keep two sets of shell state in my
head.  On the whole, running a command as root in the wrong directory
seems more dangerous than interpreting a command as a reply to a "keep
old config file?" question.

What's really optimal will depend on the individual.  It's a matter
between the human and eir shell; it is not apt-get's place to interfere
with that relationship.

-zefram


Reply to: