Opened 8 years ago
Last modified 2 years ago
#53404 new defect
`port upgrade outdated` changes colours in terminal emulation
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | Cc: | Peter_Dyballa@…, raimue (Rainer Müller) | |
Port: |
Description
When I run sudo port upgrade outdated
it produces for example this output:
---> Computing dependencies for openssl ---> Fetching archive for openssl ---> Attempting to fetch openssl-1.0.2k_0.darwin_16.x86_64.tbz2 from http://nue.de.packages.macports.org/openssl ---> Attempting to fetch openssl-1.0.2k_0.darwin_16.x86_64.tbz2.rmd160 from http://nue.de.packages.macports.org/openssl ---> Installing openssl @1.0.2k_0 ---> Cleaning openssl ---> Computing dependencies for openssl ---> Deactivating openssl @1.0.2j_0 ---> Cleaning openssl ---> Activating openssl @1.0.2k_0 ---> Cleaning openssl ---> Updating database of binaries ---> Scanning binaries for linking errors ---> No broken files found.
The last line is coloured in red – and this colour is the propagated and colours prompt, input, and output. See attached screenshot!
Attachments (9)
Change History (23)
Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | red hering, no – terminal!.png added |
---|
Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Colours are back!.png added |
---|
Colours are restored when another well programmed application sets a colour
comment:1 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
The second screenshot shows once more that the colour setting in the bash command line prompt is not able to change the wrong colour port has set. I have use actively another programme to normalise the colours. (ec2list is some Python script.)
comment:2 follow-up: 3 Changed 8 years ago by raimue (Rainer Müller)
Cc: | raimue added |
---|---|
Component: | ports → base |
Keywords: | macOS Sierra GNU Emacs removed |
Port: | port removed |
Please see TicketsKeywordGuidelines.
This might be caused by the progress bar during scanning. The terminal escape sequences used there are not supposed to change color. Which terminal emulator is this? What is the value of $TERM?
comment:3 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to raimue:
This might be caused by the progress bar during scanning. The terminal escape sequences used there are not supposed to change color. Which terminal emulator is this? What is the value of $TERM?
dumb
comment:4 follow-up: 5 Changed 8 years ago by raimue (Rainer Müller)
That answers one part of my question. Is this Terminal.app?
TERM=dumb
is not a sane choice. I wonder where this comes from in your setup. Usually, it should be TERM=xterm
or TERM=xterm-256color
, matching the capabilities of the terminal emulator.
comment:5 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to raimue:
That answers one part of my question. Is this Terminal.app?
No, it's the *shell* buffer inside
GNU Emacs`.
TERM=dumb
is not a sane choice. I wonder where this comes from in your setup. Usually, it should beTERM=xterm
orTERM=xterm-256color
, matching the capabilities of the terminal emulator.
Since GNU Emacs
performs a lot of things inside that buffer it's not really efficient when GNU Emacs
and some thought smart shell try to perform nifty things. IMO GNU Emacs
performs pretty well. If not better …
There is also a more ANSI conforming
terminal emulation, the *ansi-term buffer*
. Its TERM is set to eterm-color
. Next week, when some installed ports might have been upgraded, I can try to see how this mode performs.
comment:6 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
This ansi-term in GNU Emacs is too dumb to be useful… it's just like a piece of hardware, allows via bash to scroll in command history, but I have no change to insert and execute the contents of macros – and possibly it's not possible to work on the contents of this *ansi-term*
buffer.
It's ok for those folks who have endless time to achieve something. I'm not going to use it.
comment:7 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
It behaves quite correct, nothing from this loading bars changed the colour. (Was there any colour?)
comment:8 Changed 8 years ago by neverpanic (Clemens Lang)
The relevant code that implements this is in https://github.com/macports/macports-base/blob/master/src/port/port.tcl. I'd merge a patch that fixes the behavior for dumb terminals.
We have Tcllib available, which has some terminal control functions; see http://tmml.sourceforge.net/doc/tcllib/index.html#DIVid81bb738. Maybe one of those already deals with this correctly and we'd just have to use the correct sequences from ::term::ansi::code::attr::*
to make this work?
comment:9 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Has duplicate #61357. So far it seems like this is a problem in emacs, not a problem in MacPorts.
comment:10 Changed 4 years ago by ballapete (Peter "Pete" Dyballa)
The problem is handled by GNU Emacs developers here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44118.
comment:11 Changed 4 years ago by ballapete (Peter "Pete" Dyballa)
The bug in GNU Emacs 28.0.50, i.e. in port emacs-devel
seems to have been fixed. I ran port -vd upgrade outdated
in GNU Emacs' shell buffer and it did not happen that all the text became red. I could observe that colour changed for different sort of output from port or other tools till the end. It changed forwards and backwards many times.
comment:12 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
The problem is not solved yet, or it was solved only a preliminary release like 28.1.91 or such. It still exists can easily be triggered as shown in the attached screenshot.
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port in GNU Emacs and ticket #53404.png added |
---|
The final scan after successfully installing a port resets tty mode
comment:13 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
The picture is taken on macOS High Sierra, Version 10.13.6
in recent emacs @28.2_0+x11 (active) requested_variants='+x11' platform='darwin 17' archs='x86_64' date='2022-09-21T13:03:19+0200'
. Works similarly in Monterey
.
comment:14 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
The GNU Emacs support demands to use their programme without configuration, i.e. "vanilla", if I understand this term correctly. Therefore it is launched with -Q
. The additional argument -nw
tells GNU Emacs not to launch with its own windows or frames. For comparison I did also uninstall/install a port leaf
in XTerm and in Terminal. Obviously GNU Emacs only with its own X11 windows or without windows in XTerm is susceptible for signals from port's scan.
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port upgrade in GNU Emacs -Q and ticket #53404.png added |
---|
Port upgrade in X client GNU Emacs 28.2 -Q on High Sierra
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port install in GNU Emacs -Q -nw in XTerm and ticket #53404.png added |
---|
Port install in GNU Emacs 28.2 -Q in XTerm on High Sierra
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port install in GNU Emacs -Q -nw in Terminal and ticket #53404.png added |
---|
Port install in GNU Emacs 28.2 -Q in Apple Terminal on High Sierra
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port install in Terminal and ticket #53404.png added |
---|
Port install directly in Apple Terminal on High Sierra
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port install in XTerm and ticket #53404.png added |
---|
Port install directly in XTerm on High Sierra
Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Attachment: | Port install in Emacs.app -Q in Terminal and ticket #53404.png added |
---|
Port install in Emacs.app -Q and ticket #53404
Screenshot showing the effects of red colour plus list of active modes in GNU Emacs shell buffer