Your message dated Wed, 20 May 2020 20:01:13 -0700 with message-id <cabkpoevfvlx1cjrg3pinjxfeo0urtfhyne7g3pgoztbbz2z...@mail.gmail.com> and subject line ucf: "start a shell" option doesn't begin a new session, breaks terminal has caused the Debian Bug report #919885, regarding ucf: "start a shell" option doesn't begin a new session, breaks terminal to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 919885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919885 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: ucf Version: 3.0038+nmu1 Severity: normal Selecting the "start a shell" option in ucf is fine for running simple shell commands like cat, ls, cp, etc... but if you interact with it more you'll discover it hasn't properly detached itself and begun a new session. In particular if you run a fullscreen editor like `vim` (because you wanted to vimdiff between the old and new config files), you'll find that trying to hit <Ctrl-Z> to background that vim will break everything. The situation at that moment will be: (outer) bash +-- apt-get update +-- ucf +-- (inner) bash +-- vimdiff My intention when pressing <Ctrl-Z> was to background just the vimdiff and return to the inner bash that ucf had started. What actually happened was that it backgrounded the entire set of processes, upto and including the apt-get update, leaving me at the outer bash. This happened without any of the usual terminal suspend logic running in e.g. vim, meaning we're still in full altscreen mode, having not cleared the screen, running the wrong termios settings, with mouse reporting enabled, etc etc... This quite strongly confuses the outer bash which wasn't expecting to receive mouse report events. At this point realising my mistake, I `fg`, which makes the problem even worse, as now apt or ucf resumes and generally the terminal is in quite a mess. I couldn't easily work out a way out of this situation short of `kill -9` every process involved, and begin a resuce attempt with $ dpkg --reconfigure -a $ apt-get install -f Fixing this issue would be useful, as it would make running a subshell less painful. This also relates to #358154 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358154 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ucf depends on: ii coreutils 8.30-1 ii debconf 1.5.69 ii sensible-utils 0.0.12 ucf recommends no packages. ucf suggests no packages. -- debconf information: ucf/conflicts_found: * ucf/changeprompt_threeway: keep_current ucf/title: * ucf/changeprompt: keep_current * ucf/show_diff:
--- End Message ---
--- Begin Message ---Hi, ucf does not start a real terminal because it really cannot: it is called from a variety of debconf front-ends which connect to ucf via a pipe. We explicitly connect STDIN and STDOUT to the script's controlling terminal, so even if STDIN is fed by a pipe, as is the case when run from /usr/bin/debconf, the shell should be ""fully"" functional. However, the test for a controlling terminal uses /usr/bin/tty, which consults only STDIN. As far as I can tell, when run from debconf, ucf will _never_ use the current terminal. If the goal is to check for access to a terminal, the test should be for foreground process group membership, not a terminal connected to STDIN (tty -s), and not a terminal it doesn't necessarily own (tty -s </dev/tty). The easiest way do this from a shell is probably with /bin/ps. The downside of connecting to the controlling processes terminal is that if you try to use shell control commands, you will suspend/exit the top level process. I don't think there is a alternative. Manoj -- The Basis of the Universe Isn’t Matter or Energy—It’s Data Manoj Srivastava <[email protected]>
--- End Message ---
