Microsoft Edit

Yeah ... I don't think there's any overlap between "users largely unfamiliar with terminals" who want something easy to use, and 'Linux users who are sufficiently technical that they would even hear about this repo'.

well the editor was obviously designed primarily for Windows, not sure why the title says Linux

The title is a bit confusing depending how you read it. Edit isn't "for" Linux any more than PowerShell was made for Linux to displace bash, zsh, fish, and so on. Both are just also available with binaries "for" Linux.

The previous HN posts which linked to the blog post explaining the tool's background and reason for existing on Windows cover it all a lot better than a random title pointing to the repo.

There's no shortage of less technical people using nano for editing on Linux servers. Something even more approachable than that would have a user base.

Here's a scenario. You're running a cluster, and your users are biologists producing large datasets. They need to run some very specific command line software to assemble genomes. They need to edit SLURM scripts over SSH. This is all far outside their comfort zone. You need to point them at a text editor, which one do you choose?

I've met biologists who enjoy the challenge of vim, but they are rare. nano does the job, but it's fugly. micro is a bit better, and my current recommendation. They are not perfect experiences out of the box. If Microsoft can make that out of the box experience better, something they are very good at, then more power to them. If you don't like Microsoft, make something similar.

I dunno, I spent a lot of years (in high school at least) using Linux but being pretty overwhelmed by using something like vim (and having nobody around to point me to nano).

EDIT.COM, on the other hand... nice and straightforward in my book

Especially noting it's a single binary that's just 222kb on x86_64— that's an excellent candidate to become an "installed by default" thing on base systems. Vim and emacs are both far too large for that, and even vim-tiny is 1.3MB, while being considerably more hostile to a non-technical user than even vim is.

I can definitely see msedit having a useful place.

> You need to point them at a text editor, which one do you choose?

mcedit ?

Midnight commander comes with mcedit.

TIL PowerShell exists for Linux.

But.. why?

It's a windows 11 terminal editor. Don't get confused by the fact that it also works on Linux.

> You're running a cluster, and your users are biologists producing large datasets. They need to run some very specific command line software to assemble genomes. They need to edit SLURM scripts over SSH. This is all far outside their comfort zone. You need to point them at a text editor, which one do you choose?

Wrongly phrased scenario. If you are running this cluster for the biologists, you should build a front end for them to "edit SLURM scripts", or you may find yourself looking for a new job.

> A Bioinformatics Engineer develops software, algorithms, and databases to analyze biological data.

You're an engineer, so why don't you engineer a solution?

Well why not?

Is there supposed to be a single elected shell for Linux? Powershell on Linux is just one of plenty others.

I'm not against it. Absolutely go for it.

I just wonder what was the reason to port it and then I would like to have a word with a real living person who is actually using that shell.

I believe this was the original announcement https://azure.microsoft.com/en-us/blog/powershell-is-open-so.... I have used it on Linux and it is included by default in Kali and ParrotOS.

I dunno, I use edit since I've heard of it instead of figuring out why my vim config breaks on windows

I might use nano via wsl (Or at that point just nvim), but that also has it quirks

It occupies the same space as micro did for me, but it's / it will be preinstalled so it's better (Also a reason I even cared for vi at first)

Well, parts of it do, anyway.

As with .net, it is not intended to let you easily get away from Microsoft.

https://learn.microsoft.com/en-us/powershell/scripting/whats...

PowerShell lends itself really well to writing cross-platform shell scripts that run the same everywhere you can boot up PowerShell 7+. It's origins in .NET scripting mean that some higher-level idioms were already common in PowerShell script writing even before cross-platform existed, for instance using `$pathINeed = Join-Path $basePath ../sub-folder-name` will handle path separators smartly rather than just trying to string math it.

It's object-oriented approach is nice to work with and provides some nice tools that contrast well with the Unix "everything is text" tooling approach. Anything with a JSON output, for instance, is really lovely to work with `ConvertFrom-Json` as PowerShell objects. (Similar to what you can do with `jq`, but "shell native".) Similarly with `ConvertTo-Json` for anything that takes JSON input, you can build complex PowerShell object structures and then easily pass them as JSON. (I also sometimes use `ConvertTo-Json` for REPL debugging.)

It's also nice that shell script parameter/argument parsing is standardized in PowerShell. I think it makes it easier to start new scripts from scratch. There's a lot of bashisms you can copy and paste to start a bash script, but PowerShell gives you a lot of power out of the box including auto-shorthands and basic usage documentation "for free" with its built-in parameter binding support.

That's a very good and insightful comment. Thank you!