tab character spacing

I’m getting some odd behavior from the horizontal tab character on a system. Rather than advancing to the next tab stop (every eight spaces) it advances all the way to the end of the line (however long that is for the shell window at the time).

So where I would expect:

PS \> echo "A`tA"
A       A                                                                      

I instead get:

PS \> echo "A`tA"
A                                                                             A

It seems like the tab stops are just missing, but I don’t know why that would be.
This is PowerShell 5.1 on Windows 10 Enterprise r1909, on a domain joined system. I don’t know if this is a configurable option (not one that I can find), or the result of a group policy, or some registry setting somewhere - I don’t know where to start looking.
It is not a result of my PowerShell profile (I removed it), and the issue persists in new sessions, after gpupdate /force, and after system reboot.
The only relevant thing I’ve found is this post on superuser, but it’s not particularly helpful.

Does anyone know what to look at that might affect this?

That’s odd.

Not sure if it is related but what do you have under “Current Code Page” (PowerShell Properties –> Options Tab)?

Do you experience the same issue in both PowerShell and PowerShell ISE?

Are you able to log into the same computer with a different user account or run PowerShell as a different user from your session?

What if you run ‘(“A`tA”).Length’? I get ‘3’ as output

Current code page:
437 (OEM - United States)

I haven’t ever changed this from default.

In the ISE console the tab character behaves normally, although it seems to be produced as a single whitespace character rather than a number of spaces (when I select the text it highlights as a single block). I expect that ISE’s behavior is completely different from the normal shell in this regard.

I had another user log in to the same system, and their account does not have the issue.
I logged into another system on the same domain with my account, and I still have the issue.
So it seems to be a domain account configuration issue… somewhere. Still not sure what to actually look for.

This is a clever idea, but I also just get 3, which I guess makes sense because the tab is just a single character.

It does seem to be following your account then. Have you run rsop.msc or gpresult /H? It is painful to go over all policies but it may help you find the one that is doing this.

Personally, I prefer RSOP. And in theory, one only need focus on the “User Configuration” section so it shouldn’t be too painful.

Interesting issue. Tab is odd as I thought a tab was 5 ‘spaces’, but had to do 7 to align with the tab characters:

PS C:\Users\rasim> 'A{0}A' -f "`t"       

A       A
PS C:\Users\rasim> 'A{0}A' -f (' ' * 7)  

A       A
PS C:\Users\rasim> 'A{0}A' -f [char]9    

A       A
PS C:\Users\rasim> 

Well, you say that…

We have quite a few policies in place, most of them pointed at various bits of Office (including ~100 just in Extra Registry Settings). There aren’t any that are specifically for PowerShell, and nothing under System or Windows Components seems particularly relevant.

Does this leave me at either disabling policies one by one and testing -or- deleting the domain account and creating a new one?

Rather than being a fixed number of spaces, tab stops should be placed at every 8 spaces. It is (or should be) a convenient way to align output for readability. You should be able to do this:

PS \> "A`tA`t A`n A`tA`t-A"
A       A        A
 A      A       -A

Can you replicate the problem in cmd.exe?

Both powershell.exe and cmd.exe run under conhost.exe. If you can replicate the problem in CMD, then I would look at conhost.exe settings. I can’t find anything specific about setting tab stops except under virtual terminal emulation but it might be worth poking around under HKCU\Console to see if there are any relevant registry settings.

I don’t think you can echo a tab directly in CMD but you can do it from a file:

echo a<press left-alt and 9 together>a > c:\temp\testfile.txt
echo c:\temp\testfile.txt

 

 

This is an interesting one. What hex values do you get from the following:

“A`tA” | Format-Hex

I get the following as expected:

41 09 41

I get the same (41 09 41), in case it helps to confirm the expected output.

~grokkit checks~

41 09 <opacity=100 text='Malware successfully installed'> 41

:slight_smile:

I created test.txt which looks like

A       A       A
 A      AAA     A

Which is essentially
A[tab]A[tab]A[newline][space]A[tab]AAA[tab]A

In cmd.exe:

C:\>type test.txt
A       A       A
 A      AAA     A

So, as expected.

In powershell.exe:

PS \> Get-Content test.txt
A                                                                             A
A                                                                              
 A                                                                            A
AA                                                                            A

So, it prints the first A, then the tab advances to the last column of the line and prints the second A, then tab advances to the beginning of the next line and prints the third A, then newline, then the space and the fourth A, then tab advances to the end of the line and prints the first of the AAA set and then line wrapping continues the set on the next line, and then the final tab advances to the end of the line and prints the final A.

From what I can tell, the powershell.exe console only has stops at the beginning and end of the line, and is missing the tab stops that should be every 8 spaces along the line.

Interestingly, if I use Get-Content in cmd.exe the output is as expected:

C:\>powershell Get-Content test.txt
A       A       A
 A      AAA     A

doskey /MACROS:ALL returns nothing, so there are no macros set in cmd.exe. As far as I know, type is built in to cmd.exe, so type and powershell Get-Content executed in cmd.exe should be doing entirely different things to produce the same output.

“A`tA” | Format-Hex also returns 41 09 41 for me. I don’t think this is a character interpretation issue.

The issue seems to be tied to the powershell.exe application itself (as Matt pointed out, both powershell.exe and cmd.exe interface with conhost.exe, so I think the problem must be before that point). I think it must be related to the display handling in powershell.exe (related to .NET maybe?). But, it’s not an issue with the local application install, because the problem follows my domain account to other systems, and doesn’t appear for a different user account on the same system.

There are subkeys for 32- and 64-bit PowerShell under HKCU\Console, but I’ve compared these to a system on a different domain (where I haven’t experienced this issue), and they have all the same subkey names, types and data values.

Please don’t be offended by this question … are you using roaming profiles in the domain with the issue?

Yes, and I am still learning about Active Directory architecture & administration so there are probably large gaps in my knowledge. Server administration isn’t my primary task (role separation).

Our user profiles are stored on a shared drive on a file server that is a separate from the domain controller.

I suppose that is both good and bad news. Bad in that aside from GPO User settings as the possible cause, your issue could still be nested in the bowels of your profile somewhere. Good news is this may possibly explain why it follows you around in the domain.

I would suspect somewhere under %Appdata% in one of the 3 folders here.

<Off Post warning>

While poking around in %AppData% for clues to this post, I was surprised for find a ConsoleHost_History.txt file that contained ALL of my commands entered for a long time. It was 430K in size.

Located here: %AppData%\Roaming\Microsoft\Windows\PowerShell\PSReadline

</Off Post Warning>