Console Text Editor for Nano and Server Core (and possibly back to Server 2012 Core?)
We were discussing on GitHub how it would be nice to have a console editor for Nano and Server Core and that it a big contrast to Linux LAMP where there are many choices for this.
On core, currently some of our teams install Notepad++ because they need at least the ability for both Linux and Unix line endings to parse correctly (notepad fails) because some log files are generated with linux endings (e.g. Cloud Formation local cfn-init/cfn-bootstrap) - a frequent occurrence onsoftware that was ported to Windows from Linux. Just wanted to identify that specific feature as a must have.
There is more rationale given in the original discussion here: https://github.com/PowerShell/PowerShell-RFC/issues/69#issuecomment-278769241
Tobias Weisserth commented
This is a major gap that needs to be addressed. The solution should be a built-in Windows feature, not a third party binary that needs to be installed (and trusted). If you lock your Windows Server down with device guard enabled, it's really hard to install anything - and it should be.
Whatever the solution will be, make it a Windows feature, that can be added on the fly with admin rights while device guard is enabled.
And if I had a choice, I'd vote for VIM. Please ship VIM as an optional feature in all major versions of Windows, just like you already ship OpenSSH in Windows the same way.
In the meantime https://github.com/zyedidia/micro is a nice alternative IMHO (choco install micro), when feasible.
Toft Stade commented
Agreed. Not being able to change config files via remote powershell is really limiting.
Especially when you know you can just make or even overwrite any files with copy con
Mike Bridge commented
Yes, for me coming from the Unix world, this is a huge show-stopper to using nano. I've never come across a unix distribution with no text editor, no matter how small. Using PowerShell ISE to edit files remotely (which seems to be the suggested alternative) is a horrible option, especially when you're deploying these containers who-knows-where in the cloud.