nanorc not found in elevated shell about nano-win HOT 18 OPEN

@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).

from nano-win.

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.

from nano-win.

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.

from nano-win.

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

from nano-win.

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.

from nano-win.

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

from nano-win.

@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?

from nano-win.

@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.

from nano-win.

@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:

• PowerShell/Win32-OpenSSH#1855
• PowerShell/PowerShell#13753
• PowerShell/Win32-OpenSSH#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

from nano-win.

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

from nano-win.

@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.

from nano-win.

@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.

from nano-win.

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,

from nano-win.

@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: #26 (comment).

from nano-win.

@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?

from nano-win.

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.

from nano-win.

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

from nano-win.

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

from nano-win.