Why does text show differently between Terminal and KM Window?

Very usefull

Out of curiosity: Why does the man pmset command return crazy results when run through Execute Shell Script in KM, while returning easily readable results when ran in Terminal?

Screengrab of result from KM

Screengrab of result from Terminal

In terminal if you type

echo $TERM

it will returns something like xterm-256color which is the physical output display device emulation that the shell is using.

So the "crazy results" are basically just the characters and character codes needed to produce a nice-looking display of information with underlines, bold etc. You should note that capturing the output of the shell script to a KM window won't display all the control characters that are actually being sent to your xterm-256color monitor but enough to look odd!

1 Like

Ah, thanks for the explanation! Notice now the pattern of every bolded character repeating twice, and how underlined characters are intertwined with underscores.

This might be a dumb question, but is there any way to make KM return formated results the same way as Terminal, or alternatively at least without all the added control characters?

echo $TERM

Screenshot 2023-11-28 at 15.54.29 Medium

In terminal type this:

set TERM=dumb

Then when you type man pmset you'll get something like this:

% set TERM=dumb
% man pmset
WARNING: terminal is not fully functional
Press RETURN to continue
PMSET(1)                                                   General Commands Manual                                                   PMSET(1)

NAME
     pmset – manipulate power management settings

SYNOPSIS
     pmset [-a | -b | -c | -u] [setting value] [...]

etc
etc

I honestly can't remember how to avoid the "warning", but once you press the return key the output will be plain text. But I do remember from those dim and distant Unix days that there was a whole book about terminal emulations.

The set TERM=dumb does not seem to do anything for me here on my mac. Typing the man pmset afterwards seem to me to return the same as it have used to, without the warning or option to Press RETURN to continue:

Screengrab from Terminal

But am I right in thinking that this would anyways not change how the man pmset would display in a window returned from Execute Shell Script within KM?

If the warning is being sent to STDERR instead of STDOUT then this is the clause you add to the statement (in this case, the "man" statement):

2>/dev/null

That's from memory. I can't test it right now.

Well your Execute Shell Script action would have to include the set TERM=dumb command.

I see you get an “unknown locale” warning so that’s probably the shell telling you it’s going to ignore the TERM setting and use its default. Instead of dumb you could try tty

BTW, did you echo $TERM at all. If so, what did it come back with?

I remember that too @Airy, but the warning is followed by a request to press the enter key, and it's that that's causing the issue!

Thank you @tiffle for splitting this out into a new topic!

Here I reveal my level of competence when it comes to scripting, because this is something I am not sure how to do. I've tried set TERM=dumb | man pmset but it does not seem to make any difference to how the man pmset is returned within KM. The same happens with set TERM=tty (i.e. nothing), both from KM and in Terminal.

Jupp, it returns xterm-256color in Terminal, and dumb from KM

Well, I've tried every combination I can think of and I can't get any result that different to yours.

So, this is the shell script I'm using now:

export TERM=dumb
echo $TERM
man pmset

The result in terminal is this:

% export TERM=dumb
% echo $TERM
% man pmset                                                                                                                         
dumb
WARNING: terminal is not fully functional
Press RETURN to continue 
PMSET(1)                                                                     General Commands Manual                                                                     PMSET(1)

NAME
     pmset – manipulate power management settings

SYNOPSIS
     pmset [-a | -b | -c | -u] [setting value] [...]
     pmset -u [haltlevel percent] [haltafter minutes] [haltremain minutes]
     pmset -g [option]
     pmset schedule [cancel | cancelall] type date+time [owner]
     pmset repeat cancel

In KM I use this:

image

And the output I get is this:

image

So I'm unsure how to get the output to be the same using the TERM environment variable.

Maybe someone else can shed light on this?

1 Like

Thank you so much for your testing and trying to figure this out! And yes, your results look very much like mine.

It’d be very interesting if someone have a solution here. This mostly for learning and satisfying the curiosity, but I also wanted to implement the pmset manual into my version of @Airy’s PMSET Action, that I thought could be a good learning tool to have within KM, as well as a resource of conditions to use within future macros.

I think have a solution (more of a fix than a proper solution). You see, those things that you see as doubled letters aren't actually doubled letters. They are two of the same letters separated by an actual ^H character which KM isn't showing, even though it's there. First, do this:

image

which produces:

PMSET(1)                    General Commands Manual                   PMSET(1)

N^HNA^HAM^HME^HE

Next, do this: (where \x08 represents the backspace character)

image

which produces:

PMSET(1)                    General Commands Manual                   PMSET(1)

N@NA@AM@ME@E

Now for the fix:

image

which produces this:

PMSET(1)                    General Commands Manual                   PMSET(1)

NAME

That appears to be a valid fix to the problem. By removing the head command, you get the correct results:

PMSET(1)                    General Commands Manual                   PMSET(1)

NAME
     pmset – manipulate power management settings

SYNOPSIS
     pmset [-a | -b | -c | -u] [_______ _____] [...]
     pmset -u [haltlevel _______] [haltafter _______] [haltremain _______]
     pmset -g [______]
     pmset schedule [cancel | cancelall] type date+time [owner]
     pmset repeat cancel
     pmset repeat type weekdays time
     pmset relative [wake | poweron] seconds
     pmset [touch | sleepnow | displaysleepnow | boot]

DESCRIPTION
     pmset manages power management settings such as idle sleep timing, wake
     on administrative access, automatic restart on power loss, etc.

     Note that processes may dynamically override these power management
     settings by using I/O Kit power assertions.  Whenever processes override
     any system power settings, pmset will list those processes and their
     power assertions in -g and -g assertions. See caffeinate(8).

SETTING
     pmset can modify the values of any of the power management settings
     defined below. You may specify one or more setting & value pairs on the
     command-line invocation of pmset.  The -a, -b, -c, -u flags determine
     whether the settings apply to battery ( -b ), charger (wall power) ( -c
     ), UPS ( -u ) or all ( -a ).

image

1 Like

That’s the one! I had a whole shelf of O’Reilly books!

1 Like

Thank you! I was thinking something like this using regex, or in your case Shell, could give a possibility for a functioning workaround!

Only problem is that I must admit i do not understand how the three steps you present could be inplemented into one single workflow.
Or is it only the last step, the fix, I should use? This returns only the first three lines, that seems to be making sense as this is what the head -n 3 part does, right? But when I remove that specific part here the script fails.

There's really only one step. (I was just documenting my thought flow for educational purposes.) Try this:

image

The string you need is:

| sed 's/\x08.//g'

1 Like

Thank you, I really appreciate it! I sadly was in a bit of a hurry, and I’ll look at your reply more closely when I am back by my computer again, in a couple of hours. I also have the sneaking feeling that I messed up something, with the vertical bars or something, when removing the head-part

In Shell commands, the vertical bars are Pipes that connect the output of one command to the input of another. You could replace them with saving the output of one command to a file and then reading that file with the next command, but a single "|" is much simpler and, when you get used to it, more readable because the concept is clearer.

1 Like

I must have mistyped something because now it works and gives me the same results as you displayed.

But I now noticed that this fix doesn't play all nicely with the underlined characters (the ones resulting in intertwined underscores in KM before the fix). As exemplified by line 7, (displayed as bottom line) both from your results and mine:

From KM with fix

man pmset | man pmset | head -n 7 | sed 's/\x08.//g'

PMSET(1)                    General Commands Manual                   PMSET(1)

NAME
     pmset – manipulate power management settings

SYNOPSIS
     pmset [-a | -b | -c | -u] [_______ _____] [...]
From KM without fix

``

PMSET(1)                    General Commands Manual                   PMSET(1)

NNAAMMEE
     ppmmsseett – manipulate power management settings

SSYYNNOOPPSSIISS
     ppmmsseett [--aa | --bb | --cc | --uu] [_s_e_t_t_i_n_g _v_a_l_u_e] [...]
From Terminal

man pmset | head -n 7

Unknown locale, assuming C
PMSET(1)                    General Commands Manual                   PMSET(1)

NAME
     pmset – manipulate power management settings

SYNOPSIS
     pmset [-a | -b | -c | -u] [setting value] [...]

The fix seems to sometimes be removing the originally underlined wanted character, together with the ^H; instead of removing both of the unwanted characters, _ and ^H. Do you see any way around this behaviour @Airy?

Oh! I didn't see that. I may have a solution. Hold on.

Yes, the problem in this case is that the underscore is the first character, not the second, so my moving the dot before the backspace, I think it will work. Use this string instead:

| sed 's/.\x08//g'

Of course now the underline character disappears instead of the text character.

Ultimately, the real solution is for someone to figure out how to redefine the terminal so that the man command generates output compatible with, say, RTF. That way it would appear as desired. My fix is just a temporary workaround.

1 Like