nanorc not found in elevated shell

[rkitover]

OS: Microsoft Windows [Version 10.0.22523.1000]

nano: GNU nano from git, v5.9-10-gbe0fb5d4a

ssh: OpenSSH_for_Windows_8.6p1, LibreSSL 3.3.3

When using nano in the Windows terminal in PowerShell, syntax highlighting colors work correctly.

But in an ssh session to Windows, there are no colors.

I downloaded nano from your builds page:

https://files.lhmouse.com/nano-win/

I am using OpenSSH for Windows with the shell set to the latest PowerShell:

Name                           Value
----                           -----
PSVersion                      7.2.1
PSEdition                      Core
GitCommitId                    7.2.1
OS                             Microsoft Windows 10.0.22523
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

BTW, the package in Chocolatey is ancient, and I wrote this installer script:

https://gist.github.com/rkitover/b0831d048755c7d034b0a936b2a50604

[lhmouse]

This is most likely WONTFIX.

On Linux, colors are implemented by sending special control characters to the terminal, so they work as long as the terminal (emulator) recognizes them, and it does not matter whether they are sent via pipes or an SSH connection. On Windows, colors are implemented by calling Windows APIs directly, so it will not work over SSH.

I believe MSYS2 nano does not have such limitation, but it has others. For example, Alt-Delete (to delete the entire line) works only in MinTTY and does not work in CMD.

[rkitover]

The new Windows terminal supports both console colors and ANSI colors, so using normal ANSI colors, the control codes you speak of, will work correctly for anyone using a recent version of Windows. It will also work in the older console app in Windows 10 at least.

As for Windows console colors, they generally do work over ssh. For example, Chocolatey uses them and it works fine in an ssh session.

This is an example of a PowerShell command that uses console colors:

write-host TEST -foregroundcolor magenta

.

And this is an example of ANSI colored output:

write "`e[95mTEST`e[0m"

.

In the older Windows PowerShell use this instead:

write ([char]27 + "[95mTEST" + [char]27 + "[0m")

.

Regardless, using console colors should be fine, but the fact that they don't work over ssh indicates some other problem.

I can take a look at this, I'd like it to work.

[rkitover]

I forgot to mention that vim also works fine over ssh to Windows.

[lhmouse]

In your example you sent ANSI escape codes directly, and they turned out to work, which was expected behavior.

But GNU nano (not necessarily nano-win) doesn't send ANSI codes itself; it uses the ncurses library to control the terminal, which has a dedicated win32 console driver to manipulate the terminal with Windows APIs.

I suspect it is possible to disable the win32 console driver (see 'build_nano-win.sh' for how ncurses is configured), but this will also make nano-win unusable on Windows 7, or on legacy console on Windows 10. So hardly is it an option.

[rkitover]

I think I have enough info now to see if there's a simple solution and I will take a look, thank you.

[eabase]

@rkitover Hi Rafael, The git you linked, seem to indicate it was made for using with Powershell under WSL, is that correct? (Since the path constructed is a POSIX path...)

I'm trying to get this to work on Pwsh (core) under native Win10 (not via WSL), but no success. It runs correctly, but no colors at all!

Can you post your working .nanorc and also specify if you're using "Powershell Core" native or something else. I am using the latest core shell (pwsh.exe) and running it from Windows Terminal.

@lhmouse

But GNU nano (not necessarily nano-win) doesn't send ANSI codes itself... I suspect it is possible to disable the win32 console driver (see 'build_nano-win.sh' for how ncurses is configured), but this will also make nano-win unusable on Windows 7, or on legacy console on Windows 10. So hardly is it an option.

I don't quite understand, what is the problem?

[rkitover]

@eabase these builds work fine in PSCore in conhost and in the new terminal, here we were discussing a different issue, and this has nothing to do with WSL.

Run this script:

https://gist.github.com/rkitover/b0831d048755c7d034b0a936b2a50604

, and make sure to add ~/.local/bin to your $env:PATH. Or put the nano.exe there wherever you want, it doesn't matter.

[eabase]

@rkitover Yeah, sorry for the OT! (I got it to work after realizing it had to be given POSIX paths.) 💯

To me this sound like an issue with the character set code pages used. Perhaps somehow interfering with the color codes being sent.

Can you please provide a way to reproduce the issue? (I mean there are a million ways to use SSH, so what exactly are you doing?)

Having looked around at similar issues using Powershell & OpenSSH, I came across these:

• https://github.com/PowerShell/Win32-OpenSSH/issues/1855
• https://github.com/PowerShell/PowerShell/issues/13753
• https://github.com/PowerShell/Win32-OpenSSH/issues/1677

Have you tried using luit to debug the issue?

Check this out:

• https://github.com/ThomasDickey/luit-snapshots
• https://invisible-island.net/luit/manpage/luit.html
• https://unix.stackexchange.com/questions/35662/tail-f-iconv-fsjis-does-not-output-anything
• https://mosh.org/
• https://github.com/mobile-shell/mosh
• https://github.com/vmi/cocot
• https://files.bedroomlan.org/debian/pool/main/t/ttyconv/

With interesting solutions, such as:

LC_ALL=fr_FR luit ssh legacy-machine
ttyconv -r CP737 -- ssh -C [email protected]
cocot ssh lydia

[akuropka]

@rkitover, I am using the built-in OpenSSH server of Windows (OpenSSH_for_Windows_8.6p1, LibreSSL 3.3.3) along with nano (nano-win_9931_v6.0-14-g010f69c0e/pkg_x86_64-w64-mingw32) and syntax highlightning works over ssh in cmd as well as powershell (Desktop v5.1, didn't try the Core one).

[lhmouse]

Oh really? I didn't expect it to work.

[rkitover]

@akuropka I realized that the choco package for openssh is extremely out of date and I installed 8.6p1 and updated to latest nano build but I still don't see colors over ssh, I haven't had a chance to look into this more yet.

[rkitover]

@akuropka @lhmouse

I think I found the issue.

I have this in my ~/.nanorc:

include "/users/rkitover/.nano/*.nanorc"

in the terminal this loads the syntax files which I got from here:

https://github.com/scopatz/nanorc

This works fine in the normal terminal, but does not work in an ssh session for some reason.

However, if I use a command such as:

nano --rcfile .nanorc .bashrc

then the colors work fine!

I can't figure out yet what is different in the environment of the ssh session to cause that.

[rkitover]

It seems that $env:USERPROFILE is not used if the user is elevated, which is the case in an ssh session because you are elevated in an ssh session. This patch fixes the problem for me:

diff --git a/src/utils.c b/src/utils.c
index 555b8421..fef5a96d 100644
--- a/src/utils.c
+++ b/src/utils.c
@@ -38,7 +38,7 @@ void get_homedir(void)

                /* When HOME isn't set, or when we're root, get the home directory
                 * from the password file instead. */
-           if (homenv == NULL || IsUserAnAdmin())
+         if (homenv == NULL && IsUserAnAdmin())
                        homenv = getenv("ALLUSERSPROFILE");

                /* Only set homedir if some home directory could be determined,

[akuropka]

@rkitover, nice to see your progress. ~~As far as I know ssh sessions are not automatically elevated and specifically set in sshd_config through the "Match Group administrators" directive.~~ Yes, users of Administrators group are always elevated. Also, absolute paths in .nanorc are recommended, see: https://github.com/lhmouse/nano-win/issues/26#issuecomment-847455521.

[rkitover]

@akuropka as far as I know ssh sessions are elevated automatically on Windows and I remove the match Group administrators in my sshd_config, that just specifies the authorized_keys file.

My problem is that the .nanorc file is not read at all, because the home dir is not set based on $env:USERPROFILE.

I think my patch is reasonable, if $env:USERPROFILE is set, use that, if not, use the $env:ALLUSERSPROFILE, does that seem reasonable to you?

[akuropka]

if $env:USERPROFILE is set, use that, if not, use the $env:ALLUSERSPROFILE

and

if (homenv == NULL && IsUserAnAdmin())

are not the same because your code does not cover the case homenv = NULL for non-Admins. I guess it's rather about if the IsUserAnAdmin() condition can be removed.

[rkitover]

Maybe, I should probably do a proper PR for this and think this through fully.

[rkitover]

There are also a couple of build issues I had to deal with, so might as well do that.