Opened 4 years ago

Last modified 3 months ago

#53404 new defect

`port upgrade outdated` changes colours in terminal emulation

Reported by: ballapete (Peter 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 (2)

red hering, no – terminal!.png (89.3 KB) - added by ballapete (Peter Dyballa) 4 years ago.
Screenshot showing the effects of red colour plus list of active modes in GNU Emacs shell buffer
Colours are back!.png (57.0 KB) - added by ballapete (Peter Dyballa) 4 years ago.
Colours are restored when another well programmed application sets a colour

Download all attachments as: .zip

Change History (13)

Changed 4 years ago by ballapete (Peter Dyballa)

Screenshot showing the effects of red colour plus list of active modes in GNU Emacs shell buffer

Changed 4 years ago by ballapete (Peter Dyballa)

Attachment: Colours are back!.png added

Colours are restored when another well programmed application sets a colour

comment:1 Changed 4 years ago by ballapete (Peter 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 Changed 4 years ago by raimue (Rainer Müller)

Cc: raimue added
Component: portsbase
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 in reply to:  2 Changed 4 years ago by ballapete (Peter 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 Changed 4 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 in reply to:  4 Changed 4 years ago by ballapete (Peter 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 be TERM=xterm or TERM=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 4 years ago by ballapete (Peter 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 4 years ago by ballapete (Peter Dyballa)

It behaves quite correct, nothing from this loading bars changed the colour. (Was there any colour?)

comment:8 Changed 4 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 7 months ago by ryandesign (Ryan Schmidt)

Has duplicate #61357. So far it seems like this is a problem in emacs, not a problem in MacPorts.

comment:10 Changed 5 months ago by ballapete (Peter Dyballa)

The problem is handled by GNU Emacs developers here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44118.

comment:11 Changed 3 months ago by ballapete (Peter 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.

Note: See TracTickets for help on using tickets.