Should Windows have a default CLI editor? | Hacker News Reader

Should Windows have a default CLI editor?

github.com

27 points9front49 comments

The author is confused about what CLI means. None of the programs listed are command-line editors. Ed and sed are examples of command-line editors. These are not. (Vim and Emacs have command lines within them, but so does VSCode, for that matter.)

Vast majority of users (especially on Windows) don't understand the difference between console, terminal, shell, and command line. So this thread treats CLI as TUI.

> Vast majority of users (especially on Windows) don't understand the difference between console, terminal

What is the difference between these on Windows?

I think in modern times these two can be used interchangeably, even in Linux. I listed it because it adds to the terminology confusion.

No, they cannot. Your tty4 or xterm underestand different commands than your shell.

Perhaps there is a more ideal world in which these converge because I cannot for the life of me understand why we need all of these concurrently.

Tangential, tty is also a term that can and should be left in the past.

>>> the difference between console, terminal

>> these two can be used interchangeably, even in Linux.

> No, they cannot. Your tty4 or xterm underestand different commands than your shell.

I think you're replying to an imaginary comment? The question was about console vs. terminal, not terminal vs. shell.

> What is the difference between these on Windows?

A command line interface (CLI), as the name implies, is a user interface pattern consisting of an application that you pass arguments to it through the command line to form a request/command to be executed by the application.

This type of user interface also covers features such as exit code and text input/output through standard streams as to allow programs to be compostable through pipes.

For example, '$ cp origin rest', '$ grep -Ri foo /opt | sort', etc.

A terminal user interface (TUI) is a type of user interface which uses a terminal's limited features to provide a windowed user interface that supports interactivity.

For example, see apps like vim, fdisk, etc.

I was asking about console vs. terminal. Not CLI vs. TUI (?)

I'd be happy to see Edit come back, but honestly I think MS wants people doing as little commandline as possible.

In fact, there newest tactic is to hide configuration changes they don't want users to mess with in commandline only powershell options that are typically poorly documented, and have odd syntax.

maybe isn't malicious, but it feels like it.

I think it feels like the inverse. It seems like MS wants people to use more CLI and has been retrofitting PowerShell as a full-fledged Windows administration layer. But the problem with it being retrofitted is it feels very clunky and difficult to explore.

There's also Windows Terminal which seems like a genuine attempt at making interacting with shells in Windows less painful in general.

At a server side I would agree but from windows desktop it feels different, I should have clarified that.

Not at all, that is Microsoft appealing to the UNIX culture, that everything should be headless on a server.

Hence Windows Nano Server, and everything configuration setting being available via scripting.

I thought HN would appreciate that.

I personally have little interest in Windows servers these days. I'm more interested in automating painful settings and actions on my remaining Windows VMs that I use for some desktop applications or maintain just in case I need one in a pinch.

One task I wanted to do was have my Windows VM boot in the night and install all updates before shutting down and creating a snapshot. Windows has a pretty jank update system but I was kind of shocked there is no command line way built into windows to trigger "run all the updates now". Despite their obsession with preventing people turning updates off and rebooting against user wishes they didn't build in a way to actually just run them on a controlled schedule.

I ended up needing to install a 3rd party powershell package some one made to get this functionality which is ridiculous and arguably somewhat of a security risk.

More than scripts, an hybrid web/scripting approach. You set up the settings in a web panel, and then you should be able to export the cfg/scripts to a zip file to be scripted/applied afterwards.

Like IIS used to have in the old days, ActiveX/ASP managed.

Nowadays the new Windows Admin Center,

https://learn.microsoft.com/en-us/windows-server/manage/wind...

I would love a modern take. I don't want to see vim or emacs recreated (they exist already).

>> I don't want to see vim or emacs recreated (they exist already).

Why would they need to be recreated?

Windows ports of vim and emacs exist and they would be excellent choices along with a simple editor like nano.

I agree with those in the thread that they should just include vim, emacs, and nano.

They are mature, have excellent features and would target all the major groups of users who use text editors.

Creating an entirely new text editor seems silly when there are so many good choices with full ecosystems and user communities.

> Why would they need to be recreated? Windows ports of vim and emacs exist

I think you are missing the point here. It's not about litterally rewriting them, but about copying their design. It'd be nice to see a new advanced text editor written using what we've learned over the last 40 years and about usability, discoverability, etc.

>> I think you are missing the point here.

No, the point is to select one or more existing text editors to add to Windows:

"The goal would be to install the selected editor(s) by default such that their commands work out-of-the-box. Example editors include but are not limited to:

• Edit

• Pico

• Nano

• Vim

• Emacs

• etc.

Installing one or more of these editors by default will offer immediate CLI text editor capabilities on all Windows machines, preventing the need for additional installs or workarounds when operating on local machines, remote connections, or Windows containers."

Microsoft is not trying to create a new text editor.

If anyone wants to write their own new advanced text editor or whatever, they can, but that is not what the GitHub issue is about.

I agree, I would love to see something modern that works for devs today and isn’t just a port of something that was put together in the past.

Helix feels like a cli VSCode to me, in the sense it has TreeSitter and LSP built-in and support for most languages out the box. It’s doesn’t require loads of plugins to be useful.

A command line version of VSCode would be interesting.

Does anyone know why they removed "edit" from 64 bit versions of windows? I assume there's a newoldthing about it.

It is the MS-DOS Editor, so it's probably 16-bit, so it doesn't run on 64-bit Windows.

that discussion is wild... just install a few of the most popular editors and be done with it. default to whatever the smallest, simplest one is—nano or similar? support setting $EDITOR or whatever the fuck the Windows equivalent should be and you're done.

I guess using winget to install neovim, micro or helix isn't that problematic.

"There are plenty of offline scenarios where this would be incredibly useful. For disconnected environments, etc. There are some environments that will never connect to winget."

Source: https://github.com/microsoft/terminal/discussions/16440#disc...

It’d be much more impactful if critical OS configuration was done either via text files (ala *nix) or cli. Either would need to be feature complete and discoverable/documented very well.

> a lá *nix

Windows is not UNIX, we ought to keep it that way. Its object-oriented model is in many ways better than UNIX's everything-is-text-or-a-bunch-of-bytes model.

> if critical OS configuration was done either via text files

Ah, please, no. On Linux today we have a terrible jumble of configuration files in .conf, .ini, .yaml, .toml, even .json and .xml...

IMO the Windows Registry was a fantastic way to store settings, and Microsoft should return its usage. It's not like Linux distro don't have something similar in systemd...

> It's not like Linux distro don't have something similar in systemd...

You mean dconf? What part of systemd is like the registry?

Forgive me if I'm speaking completely in erro, but doesn't Powershell allow the latter, by exposing every Windows API known to man?

Some settings changes happen are effected via undocumented registry changes that you have to make directly, and can be a pain to track down.

Sometimes you can do something via PowerShell, but only by using PowerShell to directly call some 'raw' .NET API.

Sometimes there's a native CLI utility that'll do what you want, but it's one of the DOS-like, pre-PowerShell commands, and the PowerShell equivalent is missing or unsuitable.

Even when a native PowerShell API exists, it can be difficult to find the documentation for it because Windows culture is to document GUI solutions first (and often GUI solutions only).

Try as one might, Windows remains a platform inherently hostile to automation. Doing automation and/or configuration management on Windows sucks.

powershell doesn't expose everything by default, there are insane numbers of modules that are community created though.

What can't you access through a combination of wmi and pinvoke?

I used to use wmi in my software to manage printer ports. In the end I had to remove it because wmi was broken on a significant number of my customers machines.

You can, it’s just that going the PInvoke route can be quite complicated. It can certainly be done but typically finding a good community module that has already done so makes things a lot easier.

You can already do the cli way via PowerShell, what would be more impactful if the GUI way of configuring the OS were good

What do you mean by "critical"? Do you mean stuff that everyone will have to do, like changing mouse speed? Installing programs? The more obscure stuff, like Event Viewer? The really obscure changes that currently need registry hacks (the "I know my setup is weird but it works for me" stuff)?

Different demographics will probably need different solutions. The important thing isn't what solutions they come up with, it's that they choose a system and stick with it. To me it's understandable that Event Viewer isn't part of the main Settings app (plenty of IT folks would be upset if anything about Event Viewer changed). But Mouse Acceleration options really should be.

Everything is available via CLI for ages, on the Windows NT linage.

VBScript, JScript and nowadays Poweshell.

Try setting Group Policy objects through CLI without some serious workarounds and without using that one Microsoft local GPO binary that I don't remember the name of but isn't supported.

https://learn.microsoft.com/en-us/powershell/module/grouppol...

Show me how to set an arbitrary, already existing, GPO's value without having to manually toggle it first, back that up, and use that backup to import the change.

I've needed to automate the addition of a cellular APN on Windows, as far as I know it's not possible to do without the Windows settings app

https://learn.microsoft.com/en-us/windows-server/networking/...

Edlin, of course.

Upvote for edlin! I didn't even need 1Mb of memory to run that. Incidentally, iPadOS autocorrects "edlin" to "delinquent".

Or an mcedit clone, as mcedit it's a merge between DOS edit design and the midnight commander tools.

I guess you didn't got the joke with edlin. :)

Bring back EDLIN!

Reply on news.ycombinator.com