Bug#728775: apt-get unwarrantedly consumes input
On Tue, Nov 05, 2013 at 11:40 +, Zefram wrote: When apt-get is invoked in a way that involves actually installing a package, it reads any available data from standard input, regardless of actual need. This breaks the usual ability, at an interactive shell, to type the next command while the current one is running: apt-get consumes input that was intended for the shell. Hi Zefram, 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. There is an undocumented control flag DPkg::FlushSTDIN. It was added for the use case of scripted responses to dpkg's prompts (bug #63991), before debconf existed. Also the fix added for bug #192228 should also work for #63991's use-case. So that flag should possibly be removed rather than documented. But for your use-case of an interactive shell, wouldn't it be safer to just open another terminal? Cheers, Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728775: apt-get unwarrantedly consumes input
Package: apt Version: 0.9.7.9 Severity: minor When apt-get is invoked in a way that involves actually installing a package, it reads any available data from standard input, regardless of actual need. This breaks the usual ability, at an interactive shell, to type the next command while the current one is running: apt-get consumes input that was intended for the shell. strace shows that the input is read by the top-level apt-get process, by read(2) from fd 0, in response to pselect(2). Presumably apt-get is reading this input in order to pass it on to interactive aspects of package installation, but it's doing it regardless of whether the installation process seeks input and, where it does want input, regardless of how much input it wants to read. This behaviour is not documented. It's not immediately obvious why apt-get has to act as an intermediary for this input at all. -zefram -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
