bugGNU Octave - Bugs: bug #51272, Color in Command line color not...

 
 

bug #51272: Color in Command line color not enabled initially

Submitter:  Marshall <marsian>
Submitted:  Mon 19 Jun 2017 11:10:44 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  Marsian Open/Closed:  * Open
Release:  * 4.2.1 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 20 Jul 2017 08:55:47 PM UTC, comment #6: 

As a temporary (ugly) work around, since I found that many system(...) calls are at the root of disabling color at the command  line, and that system('') re-enables it, I added the following to my path:


function [a,b] = system(varargin)
  [a,b] = builtin('system',varargin{:});
  builtin('system','');%restore color to command line
endfunction


I also call system('') at startup.
I am guessing there is a less ugly workaround if the octave source itself is edited, but I haven't had time yet to try and look at, edit and compile octave source yet (since I've heard compiling can take hours).

Marshall <marsian>
Mon 17 Jul 2017 06:18:22 PM UTC, comment #5: 

It looks like Matlab's command window does support ANSI color modes, so Octave should (continue to) as well.

Hopefully, a future version of Octave will have a command window that can reliably support scrollback and selection and ANSI colors and hyperlinks in a cross-platform way. But for now I suspect the Windows command window is what it is. If there is something simple that Octave can do as it is now to allow colors to be supported more reliably, we're happy to accept patches.

So I think the best solution to this is to have a completely new command window, which is a known future improvement project idea.

Mike Miller <mtmiller>
Group Member
Wed 28 Jun 2017 01:33:46 AM UTC, comment #4: 

I traced the known causes of disabling of color in the console back to system(...) calls.

1) xlsread() disables color when system('unzip ...') called in unpack().

2) The random fact that some errors disable color and some don't can be traced as far as I can tell to errors due to improper function call usage, which trigger print_usage() calls which I trace down to color being disabled after system('makinfo ...') in _makeinfo_().

This means system(...) calls both enable or disable ANSI escape character interpretation depending on what is run by the system() command.

Another odd behavior I noticed is that the ANSI coloring can persist after ANSI escape codes are no longer interpreted.
 

system("");
fprintf(2,'\033[01;31mredtext\n');
isnan(); %comment this out to have the next command work
fprintf(2,'\033[01;30mstill red text but should be black\n');


In the above the red coloring triggered by the escape sequence persists even though the second set isn't recognized.

Marshall <marsian>
Tue 20 Jun 2017 04:37:29 PM UTC, comment #3: 

I'm glad to see work is happening (or happened) on this. From looking at the comments on the patch, it supports what I've learned that Windows didn't used to support ANSI escape sequences at all. Windows 10 just recently began to support ANSI escape sequences, so now color can show up. I tested on my Win7 machine and it wouldn't show color even with the use of any of the tricks that I mentioned below.

I had looked into what enables color in Windows this last week and found that supposedly color is enabled by a specific SetConsoleMode call that switches it on or off. I believe the system("") calls turn color on because processes run by octave, such as the system call (or the output pager) turns that switch on, and something in octave, perhaps errors, switches it off. It seems that it should be easy to make sure the switch is set to on at octave startup and isn't turned off by error calls.

I would really like to see red errors, and other colored output in the windows terminal, which doesn't happen at all right now. Now you know windows 10 can support it, maybe you can enable color for Win 10 (or have an option so a user can enable it)?

Marshall <marsian>
Tue 20 Jun 2017 08:15:53 AM UTC, comment #2: 

See also patch #9024

The least that can be said is that the Octave terminal in Windows has some deficiencies :-)

I tend to close this as a duplicate of that patch #9024 but I'll leave it to the other devs.



Philip Nienhuis <philipnienhuis>
Group Member
Tue 20 Jun 2017 12:37:04 AM UTC, comment #1: 

I found another problem: Now that I can always enable color at the command prompt, I found that at least in one case, color will get disabled: If I call a function incorrectly, (e.g "test" with no argument) then after the usage is displayed, then color has been disabled.

Marshall <marsian>
Mon 19 Jun 2017 11:10:44 PM UTC, original submission:  

I'm using Windows 10, and haven't tested this on Win7 yet. I found a bug that's been bothering me for a while where I happily discovered I could show things in color on the commnad prompt in the gui using the techniques of https://www.gnu.org/software/octave/doc/interpreter/Customizing-the-Prompt.html,

PS1 ('\[\033[01;31m\]\s:\#> \[\033[0m\]')

But later no coloring would work. I thought some windows update must have been the culprit or maybe it was because I recently changed from a windows 7 to windows 10 machine, but couldn't get color to work when I went back and tested it on a different windows 7 machine. Finally, today color accidentally appeared on the command line due to output of a system() call, so I knew color WAS working after all, tried the above command, and it worked again. After restarting octave, color was gone again. I narrowed it down so I can reliably get color to be enabled by calling certain functions in octave, but color is never enabled at startup. The following things enable color: calling any system() command, a print() command (don't know if all print calls do it, because I traced it down to a non-documented form of a call to drawnow() ), and any output that uses the pager (e.g. dir(), path(), and long output to the command window: calling more off before color is enabled will disable any of the long output from enabling color.

Color should be enabled at octave startup, rather than randomly after some other function enables color at the command window inside of it.

Marshall <marsian>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by marsian (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code