Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Hello Frank, Am Samstag, 22. Oktober 2016, 19:14:44 CEST schrieb Frank Terbeck: > Michael Biebl wrote: > [...] > > martin@merkaba:~> systemctl status > > ^[[0;1;31m●^[[0m merkaba > > State: ^[[0;1;31mdegraded^[[0m > > Jobs: 0 queued > > Failed: 2 units > > I can't reproduce this. > > If zsh changed its terminal to behave like that, no coloured output > would work at all. This smells a lot like broken configuration. > > Please provide a minimal example, that triggers the problem (freshly > started terminal, preferably xterm, and freshly started zsh, with only > as much configuration as to trigger the problem). If it is indeed a > problem, that zsh is responsible for, we can talk. Funnily enough I can´t reproduce this at the moment either. I honestly have no idea what difference leads to that differing result, but given the timeframe between my original report and last tests and my test just a moment ago it could be about anything. So feel free to close. I´d reopen should I see this again. Thank you, -- Martin
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Hi, Michael Biebl wrote: [...] martin@merkaba:~> systemctl status ^[[0;1;31m●^[[0m merkaba State: ^[[0;1;31mdegraded^[[0m Jobs: 0 queued Failed: 2 units I can't reproduce this. If zsh changed its terminal to behave like that, no coloured output would work at all. This smells a lot like broken configuration. Please provide a minimal example, that triggers the problem (freshly started terminal, preferably xterm, and freshly started zsh, with only as much configuration as to trigger the problem). If it is indeed a problem, that zsh is responsible for, we can talk. Regards, Frank
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Control: reassign -1 zsh 5.2-5 Am 26.09.2016 um 23:11 schrieb Martin Steigerwald: > Am Montag, 26. September 2016, 13:53:21 CEST schrieb Josh Triplett: >> On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote: >>> Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett: On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote: > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: >> On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald >> > > wrote: >>> Package: systemd >>> Version: 231-5 >>> Severity: minor >>> >>> Dear Martin, dear Michael, dear Systemd maintainers, >>> >>> systemctl status for a long time just printed the status directly >>> onto >>> the >>> terminal (Konsole in my case). But since also quite a while it >>> uses >>> less >>> on >>> my system, even tough the output is not larger than one page. >>> >>> Also the color escape sequences are not executed by less, leavinge >>> me >>> with >>> something like: >>> >>> ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting >>> daemon >>> >>>Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; >>>vendor >>>preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since >>>So >>>2016-09-04 10:48:07 CEST; 1s ago> >>> >>> Docs: man:atopacctd(8) >>> >>> Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, >>> status=0/SUCCESS) >>> >>> Main PID: 5034 (atopacctd) >>> >>> Tasks: 1 (limit: 4915) >>> >>>CGroup: /system.slice/atopacct.service >>> >>>ââ5034 /usr/sbin/atopacctd >>> >>> Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process >>> accounting >>> daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: >>> PID >>> file >>> /run/atopacctd.pid not readable (yet?) after start: No such file >>> or >>> directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 >>> - >>> 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: >>> Started >>> Atop process accounting daemon. Sep 04 10:48:07 merkaba >>> atopacctd[5034]: >>> ^[[0;1;39mreactivate process accounting^[[0m >> >> Works fine here with systemd 231-5: "systemctl status" uses less, >> but it >> interprets color escape sequences, and exits if the output fits >> entirely >> on the screen. Can you provide your environment (output of "env"), >> and >> in particular the values of $LESS and $PAGER? And can you check if >> this >> occurs in another terminal, such as xterm? > > Thanks for your answer Josh. I missed it first seems it was sortet > more > downwards due to old date: > > > merkaba:~> systemctl status > merkaba:~> echo $LESS > > -w > > merkaba:~> echo $PAGER > > I do not know who has put that "-w" into LESS variable. > > But removing it doesn´t help: > > merkaba:~> unset LESS > merkaba:~> systemctl status > ^[[0;1;31m●^[[0m merkaba > > State: ^[[0;1;31mdegraded^[[0m > > Jobs: 0 queued > >Failed: 2 units > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago > >CGroup: / > > Same in xterm. > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 > less:amd64/sid 481-2.1 uptodate > systemd:amd64/sid 231-7 uptodate What happens if you explicitly export LESS=R ? Does that help? >>> >>> No. >>> Try running the following in your terminal: /usr/bin/printf '\e[0;1;31mRED\e[0m' Does the word "RED" show up in red? >>> >>> Yes. >>> Also try this: /usr/bin/printf '\e[2J' Does that clear your screen? >>> >>> Yes. >>> >>> Okay, I think I found something: >>> >>> martin@merkaba:~> echo $SHELL >>> /usr/bin/zsh >>> martin@merkaba:~> systemctl status >>> >>> ^[[0;1;31m●^[[0m merkaba >>> >>> State: ^[[0;1;31mdegraded^[[0m >>> >>> Jobs: 0 queued >>> >>>Failed: 2 units >>> >>> But: >>> >>> >>> martin@merkaba:~> bash >>> martin@merkaba:~ -> systemctl status >>> >>> ● merkaba >>> >>> State: degraded >>> >>> Jobs: 0 queued >>> >>>Failed: 2 units >>> >>> The red dot and degraded are in red. >>> >>> >>> So seems some interaction with Z-Shell, that leads to broken escape >>> sequences. >>> >>> I use zsh 5.2-5. >> >> Ah, interesting. Perhaps zsh puts the terminal into an unexpected mode >> somehow? >> >> Can you run zsh with whatever options cause it to ignore all your shell >> configuration and startup files? Does that fix the problem? >> >> If the *default* configuration of zsh causes this bug, I'd suggest >> reassigning this bug to zsh. > > Hmmm, no idea how to do that f
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Am Montag, 26. September 2016, 13:53:21 CEST schrieb Josh Triplett: > On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote: > > Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett: > > > On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote: > > > > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: > > > > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald > > > > > > > > > > > > > wrote: > > > > > > Package: systemd > > > > > > Version: 231-5 > > > > > > Severity: minor > > > > > > > > > > > > Dear Martin, dear Michael, dear Systemd maintainers, > > > > > > > > > > > > systemctl status for a long time just printed the status directly > > > > > > onto > > > > > > the > > > > > > terminal (Konsole in my case). But since also quite a while it > > > > > > uses > > > > > > less > > > > > > on > > > > > > my system, even tough the output is not larger than one page. > > > > > > > > > > > > Also the color escape sequences are not executed by less, leavinge > > > > > > me > > > > > > with > > > > > > something like: > > > > > > > > > > > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting > > > > > > daemon > > > > > > > > > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; > > > > > >vendor > > > > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since > > > > > >So > > > > > >2016-09-04 10:48:07 CEST; 1s ago> > > > > > > > > > > > > Docs: man:atopacctd(8) > > > > > > > > > > > > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, > > > > > > status=0/SUCCESS) > > > > > > > > > > > > Main PID: 5034 (atopacctd) > > > > > > > > > > > > Tasks: 1 (limit: 4915) > > > > > > > > > > > >CGroup: /system.slice/atopacct.service > > > > > > > > > > > >ââ5034 /usr/sbin/atopacctd > > > > > > > > > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process > > > > > > accounting > > > > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: > > > > > > PID > > > > > > file > > > > > > /run/atopacctd.pid not readable (yet?) after start: No such file > > > > > > or > > > > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 > > > > > > - > > > > > > 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: > > > > > > Started > > > > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba > > > > > > atopacctd[5034]: > > > > > > ^[[0;1;39mreactivate process accounting^[[0m > > > > > > > > > > Works fine here with systemd 231-5: "systemctl status" uses less, > > > > > but it > > > > > interprets color escape sequences, and exits if the output fits > > > > > entirely > > > > > on the screen. Can you provide your environment (output of "env"), > > > > > and > > > > > in particular the values of $LESS and $PAGER? And can you check if > > > > > this > > > > > occurs in another terminal, such as xterm? > > > > > > > > Thanks for your answer Josh. I missed it first seems it was sortet > > > > more > > > > downwards due to old date: > > > > > > > > > > > > merkaba:~> systemctl status > > > > merkaba:~> echo $LESS > > > > > > > > -w > > > > > > > > merkaba:~> echo $PAGER > > > > > > > > I do not know who has put that "-w" into LESS variable. > > > > > > > > But removing it doesn´t help: > > > > > > > > merkaba:~> unset LESS > > > > merkaba:~> systemctl status > > > > ^[[0;1;31m●^[[0m merkaba > > > > > > > > State: ^[[0;1;31mdegraded^[[0m > > > > > > > > Jobs: 0 queued > > > > > > > >Failed: 2 units > > > > > > > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago > > > > > > > >CGroup: / > > > > > > > > Same in xterm. > > > > > > > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 > > > > less:amd64/sid 481-2.1 uptodate > > > > systemd:amd64/sid 231-7 uptodate > > > > > > What happens if you explicitly export LESS=R ? Does that help? > > > > No. > > > > > Try running the following in your terminal: > > > > > > /usr/bin/printf '\e[0;1;31mRED\e[0m' > > > > > > Does the word "RED" show up in red? > > > > Yes. > > > > > Also try this: > > > > > > /usr/bin/printf '\e[2J' > > > > > > Does that clear your screen? > > > > Yes. > > > > Okay, I think I found something: > > > > martin@merkaba:~> echo $SHELL > > /usr/bin/zsh > > martin@merkaba:~> systemctl status > > > > ^[[0;1;31m●^[[0m merkaba > > > > State: ^[[0;1;31mdegraded^[[0m > > > > Jobs: 0 queued > > > >Failed: 2 units > > > > But: > > > > > > martin@merkaba:~> bash > > martin@merkaba:~ -> systemctl status > > > > ● merkaba > > > > State: degraded > > > > Jobs: 0 queued > > > >Failed: 2 units > > > > The red dot and degraded are in red. > > > > > > So seems some interaction with Z-Shell, that leads to broken escape > > sequences. > > > > I use zsh 5.2-5. > > Ah, interesting. Perhaps zsh puts the terminal into an unex
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote: > Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett: > > On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote: > > > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: > > > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald > > > > > > > > > > wrote: > > > > > Package: systemd > > > > > Version: 231-5 > > > > > Severity: minor > > > > > > > > > > Dear Martin, dear Michael, dear Systemd maintainers, > > > > > > > > > > systemctl status for a long time just printed the status directly onto > > > > > the > > > > > terminal (Konsole in my case). But since also quite a while it uses > > > > > less > > > > > on > > > > > my system, even tough the output is not larger than one page. > > > > > > > > > > Also the color escape sequences are not executed by less, leavinge me > > > > > with > > > > > something like: > > > > > > > > > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting daemon > > > > > > > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; > > > > >vendor > > > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So > > > > >2016-09-04 10:48:07 CEST; 1s ago> > > > > > > > > > > Docs: man:atopacctd(8) > > > > > > > > > > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, > > > > > status=0/SUCCESS) > > > > > > > > > > Main PID: 5034 (atopacctd) > > > > > > > > > > Tasks: 1 (limit: 4915) > > > > > > > > > >CGroup: /system.slice/atopacct.service > > > > > > > > > >ââ5034 /usr/sbin/atopacctd > > > > > > > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting > > > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID > > > > > file > > > > > /run/atopacctd.pid not readable (yet?) after start: No such file or > > > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - > > > > > 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: Started > > > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba > > > > > atopacctd[5034]: > > > > > ^[[0;1;39mreactivate process accounting^[[0m > > > > > > > > Works fine here with systemd 231-5: "systemctl status" uses less, but it > > > > interprets color escape sequences, and exits if the output fits entirely > > > > on the screen. Can you provide your environment (output of "env"), and > > > > in particular the values of $LESS and $PAGER? And can you check if this > > > > occurs in another terminal, such as xterm? > > > > > > Thanks for your answer Josh. I missed it first seems it was sortet more > > > downwards due to old date: > > > > > > > > > merkaba:~> systemctl status > > > merkaba:~> echo $LESS > > > > > > -w > > > > > > merkaba:~> echo $PAGER > > > > > > I do not know who has put that "-w" into LESS variable. > > > > > > But removing it doesn´t help: > > > > > > merkaba:~> unset LESS > > > merkaba:~> systemctl status > > > ^[[0;1;31m●^[[0m merkaba > > > > > > State: ^[[0;1;31mdegraded^[[0m > > > > > > Jobs: 0 queued > > > > > >Failed: 2 units > > > > > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago > > > > > >CGroup: / > > > > > > Same in xterm. > > > > > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 > > > less:amd64/sid 481-2.1 uptodate > > > systemd:amd64/sid 231-7 uptodate > > > > What happens if you explicitly export LESS=R ? Does that help? > > No. > > > Try running the following in your terminal: > > > > /usr/bin/printf '\e[0;1;31mRED\e[0m' > > > > Does the word "RED" show up in red? > > Yes. > > > Also try this: > > > > /usr/bin/printf '\e[2J' > > > > Does that clear your screen? > > Yes. > > Okay, I think I found something: > > martin@merkaba:~> echo $SHELL > /usr/bin/zsh > martin@merkaba:~> systemctl status > > ^[[0;1;31m●^[[0m merkaba > State: ^[[0;1;31mdegraded^[[0m > Jobs: 0 queued >Failed: 2 units > > But: > > > martin@merkaba:~> bash > martin@merkaba:~ -> systemctl status > > ● merkaba > State: degraded > Jobs: 0 queued >Failed: 2 units > > The red dot and degraded are in red. > > > So seems some interaction with Z-Shell, that leads to broken escape sequences. > > I use zsh 5.2-5. Ah, interesting. Perhaps zsh puts the terminal into an unexpected mode somehow? Can you run zsh with whatever options cause it to ignore all your shell configuration and startup files? Does that fix the problem? If the *default* configuration of zsh causes this bug, I'd suggest reassigning this bug to zsh. - Josh Triplett
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett: > On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote: > > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: > > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald > > > > > > > wrote: > > > > Package: systemd > > > > Version: 231-5 > > > > Severity: minor > > > > > > > > Dear Martin, dear Michael, dear Systemd maintainers, > > > > > > > > systemctl status for a long time just printed the status directly onto > > > > the > > > > terminal (Konsole in my case). But since also quite a while it uses > > > > less > > > > on > > > > my system, even tough the output is not larger than one page. > > > > > > > > Also the color escape sequences are not executed by less, leavinge me > > > > with > > > > something like: > > > > > > > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting daemon > > > > > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; > > > >vendor > > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So > > > >2016-09-04 10:48:07 CEST; 1s ago> > > > > > > > > Docs: man:atopacctd(8) > > > > > > > > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, > > > > status=0/SUCCESS) > > > > > > > > Main PID: 5034 (atopacctd) > > > > > > > > Tasks: 1 (limit: 4915) > > > > > > > >CGroup: /system.slice/atopacct.service > > > > > > > >ââ5034 /usr/sbin/atopacctd > > > > > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting > > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID > > > > file > > > > /run/atopacctd.pid not readable (yet?) after start: No such file or > > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - > > > > 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: Started > > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba > > > > atopacctd[5034]: > > > > ^[[0;1;39mreactivate process accounting^[[0m > > > > > > Works fine here with systemd 231-5: "systemctl status" uses less, but it > > > interprets color escape sequences, and exits if the output fits entirely > > > on the screen. Can you provide your environment (output of "env"), and > > > in particular the values of $LESS and $PAGER? And can you check if this > > > occurs in another terminal, such as xterm? > > > > Thanks for your answer Josh. I missed it first seems it was sortet more > > downwards due to old date: > > > > > > merkaba:~> systemctl status > > merkaba:~> echo $LESS > > > > -w > > > > merkaba:~> echo $PAGER > > > > I do not know who has put that "-w" into LESS variable. > > > > But removing it doesn´t help: > > > > merkaba:~> unset LESS > > merkaba:~> systemctl status > > ^[[0;1;31m●^[[0m merkaba > > > > State: ^[[0;1;31mdegraded^[[0m > > > > Jobs: 0 queued > > > >Failed: 2 units > > > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago > > > >CGroup: / > > > > Same in xterm. > > > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 > > less:amd64/sid 481-2.1 uptodate > > systemd:amd64/sid 231-7 uptodate > > What happens if you explicitly export LESS=R ? Does that help? No. > Try running the following in your terminal: > > /usr/bin/printf '\e[0;1;31mRED\e[0m' > > Does the word "RED" show up in red? Yes. > Also try this: > > /usr/bin/printf '\e[2J' > > Does that clear your screen? Yes. Okay, I think I found something: martin@merkaba:~> echo $SHELL /usr/bin/zsh martin@merkaba:~> systemctl status ^[[0;1;31m●^[[0m merkaba State: ^[[0;1;31mdegraded^[[0m Jobs: 0 queued Failed: 2 units But: martin@merkaba:~> bash martin@merkaba:~ -> systemctl status ● merkaba State: degraded Jobs: 0 queued Failed: 2 units The red dot and degraded are in red. So seems some interaction with Z-Shell, that leads to broken escape sequences. I use zsh 5.2-5. Thanks, -- Martin
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote: > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald > wrote: > > > Package: systemd > > > Version: 231-5 > > > Severity: minor > > > > > > Dear Martin, dear Michael, dear Systemd maintainers, > > > > > > systemctl status for a long time just printed the status directly onto the > > > terminal (Konsole in my case). But since also quite a while it uses less > > > on > > > my system, even tough the output is not larger than one page. > > > > > > Also the color escape sequences are not executed by less, leavinge me with > > > something like: > > > > > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting daemon > > > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So > > >2016-09-04 10:48:07 CEST; 1s ago> > > > Docs: man:atopacctd(8) > > > > > > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, > > > status=0/SUCCESS) > > > > > > Main PID: 5034 (atopacctd) > > > > > > Tasks: 1 (limit: 4915) > > > > > >CGroup: /system.slice/atopacct.service > > > > > >ââ5034 /usr/sbin/atopacctd > > > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID file > > > /run/atopacctd.pid not readable (yet?) after start: No such file or > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - > > > 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: Started > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba atopacctd[5034]: > > > ^[[0;1;39mreactivate process accounting^[[0m > > Works fine here with systemd 231-5: "systemctl status" uses less, but it > > interprets color escape sequences, and exits if the output fits entirely > > on the screen. Can you provide your environment (output of "env"), and > > in particular the values of $LESS and $PAGER? And can you check if this > > occurs in another terminal, such as xterm? > > Thanks for your answer Josh. I missed it first seems it was sortet more > downwards due to old date: > > > merkaba:~> systemctl status > merkaba:~> echo $LESS > -w > merkaba:~> echo $PAGER > > I do not know who has put that "-w" into LESS variable. > > But removing it doesn´t help: > > merkaba:~> unset LESS > merkaba:~> systemctl status > ^[[0;1;31m●^[[0m merkaba > State: ^[[0;1;31mdegraded^[[0m > Jobs: 0 queued >Failed: 2 units > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago >CGroup: / > > > Same in xterm. > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 > less:amd64/sid 481-2.1 uptodate > systemd:amd64/sid 231-7 uptodate What happens if you explicitly export LESS=R ? Does that help? Try running the following in your terminal: /usr/bin/printf '\e[0;1;31mRED\e[0m' Does the word "RED" show up in red? Also try this: /usr/bin/printf '\e[2J' Does that clear your screen?
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett: > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald wrote: > > Package: systemd > > Version: 231-5 > > Severity: minor > > > > Dear Martin, dear Michael, dear Systemd maintainers, > > > > systemctl status for a long time just printed the status directly onto the > > terminal (Konsole in my case). But since also quite a while it uses less > > on > > my system, even tough the output is not larger than one page. > > > > Also the color escape sequences are not executed by less, leavinge me with > > something like: > > > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting daemon > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So > >2016-09-04 10:48:07 CEST; 1s ago> > > Docs: man:atopacctd(8) > > > > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, > > status=0/SUCCESS) > > > > Main PID: 5034 (atopacctd) > > > > Tasks: 1 (limit: 4915) > > > >CGroup: /system.slice/atopacct.service > > > >ââ5034 /usr/sbin/atopacctd > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID file > > /run/atopacctd.pid not readable (yet?) after start: No such file or > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - > > 2015/06/25 11:07:21 [â¦] Sep 04 10:48:07 merkaba systemd[1]: Started > > Atop process accounting daemon. Sep 04 10:48:07 merkaba atopacctd[5034]: > > ^[[0;1;39mreactivate process accounting^[[0m > Works fine here with systemd 231-5: "systemctl status" uses less, but it > interprets color escape sequences, and exits if the output fits entirely > on the screen. Can you provide your environment (output of "env"), and > in particular the values of $LESS and $PAGER? And can you check if this > occurs in another terminal, such as xterm? Thanks for your answer Josh. I missed it first seems it was sortet more downwards due to old date: merkaba:~> systemctl status merkaba:~> echo $LESS -w merkaba:~> echo $PAGER I do not know who has put that "-w" into LESS variable. But removing it doesn´t help: merkaba:~> unset LESS merkaba:~> systemctl status ^[[0;1;31m●^[[0m merkaba State: ^[[0;1;31mdegraded^[[0m Jobs: 0 queued Failed: 2 units Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago CGroup: / Same in xterm. merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64 less:amd64/sid 481-2.1 uptodate systemd:amd64/sid 231-7 uptodate Thank you, -- Martin
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald wrote: > Package: systemd > Version: 231-5 > Severity: minor > > Dear Martin, dear Michael, dear Systemd maintainers, > > systemctl status for a long time just printed the status directly onto the > terminal (Konsole in my case). But since also quite a while it uses less on > my system, even tough the output is not larger than one page. > > Also the color escape sequences are not executed by less, leavinge me with > something like: > > ^[[0;1;32mâ^[[0m atopacct.service - Atop process accounting daemon >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor > preset: enabled) >Active: ^[[0;1;32mactive (running)^[[0m since So 2016-09-04 10:48:07 CEST; > 1s ago > Docs: man:atopacctd(8) > Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, status=0/SUCCESS) > Main PID: 5034 (atopacctd) > Tasks: 1 (limit: 4915) >CGroup: /system.slice/atopacct.service >ââ5034 /usr/sbin/atopacctd > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting daemon... > Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID file > /run/atopacctd.pid not readable (yet?) after start: No such file or directory > Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - 2015/06/25 11:07:21 > [â¦] > Sep 04 10:48:07 merkaba systemd[1]: Started Atop process accounting daemon. > Sep 04 10:48:07 merkaba atopacctd[5034]: ^[[0;1;39mreactivate process > accounting^[[0m Works fine here with systemd 231-5: "systemctl status" uses less, but it interprets color escape sequences, and exits if the output fits entirely on the screen. Can you provide your environment (output of "env"), and in particular the values of $LESS and $PAGER? And can you check if this occurs in another terminal, such as xterm?
Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied
Package: systemd Version: 231-5 Severity: minor Dear Martin, dear Michael, dear Systemd maintainers, systemctl status for a long time just printed the status directly onto the terminal (Konsole in my case). But since also quite a while it uses less on my system, even tough the output is not larger than one page. Also the color escape sequences are not executed by less, leavinge me with something like: ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting daemon Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So 2016-09-04 10:48:07 CEST; 1s ago Docs: man:atopacctd(8) Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited, status=0/SUCCESS) Main PID: 5034 (atopacctd) Tasks: 1 (limit: 4915) CGroup: /system.slice/atopacct.service └─5034 /usr/sbin/atopacctd Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID file /run/atopacctd.pid not readable (yet?) after start: No such file or directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 - 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]: Started Atop process accounting daemon. Sep 04 10:48:07 merkaba atopacctd[5034]: ^[[0;1;39mreactivate process accounting^[[0m I am fine with piping longer listings like "systemctl" or "systemctl status" output through less. I am aware I can disable piping through less on an ad-hoc at least by adding "| cat" to the command line. At it seems I can also alias "systemctl" to "systemctl --no-pager"¹. And I bet it was upstream making piping through less unconditional. But still even with piping through it would at least be nice if it applies escape sequences. Anyway for myself I think I will just system-globally alias systemctl back to more sanity than using less for half a page of output. [1] Bug 713567 - Output of 'systemctl --all' pipes through 'less' by default https://bugzilla.redhat.com/show_bug.cgi?id=713567 Thanks, Martin -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-rc4-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-4 ii libaudit1 1:2.6.6-1 ii libblkid1 2.28.1-1 ii libc6 2.23-5 ii libcap2 1:2.25-1 ii libcap2-bin 1:2.25-1 ii libcryptsetup4 2:1.7.0-2 ii libgcrypt20 1.7.3-1 ii libgpg-error0 1.24-1 ii libidn111.33-1 ii libip4tc0 1.6.0-3 ii libkmod222-1.1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.28.1-1 ii libpam0g1.1.8-3.3 ii libseccomp2 2.3.1-2 ii libselinux1 2.5-3 ii libsystemd0 231-5 ii mount 2.28.1-1 ii util-linux 2.28.1-1 Versions of packages systemd recommends: ii dbus1.10.10-1 ii libpam-systemd 231-5 Versions of packages systemd suggests: ii policykit-10.105-16 ii systemd-container 231-5 ii systemd-ui 3-4 Versions of packages systemd is related to: ii udev 231-5 -- Configuration Files: /etc/systemd/resolved.conf changed [not included] -- no debconf information
