Microsoft Promotes Its Open-Source Terminal To The Default For Windows 11 CLI Apps

[Quackdoc]

Used it, still terrible, folks on windows I suggest using wezterm instead

[ll1025]

I suspected it; but I am not convinced you have used tmux. You (or WareCatf) clearly don't understand its use-case. You or they are probably not a command-line guy. No, tmux is fairly good to disconnects such as ssh connection broken or terminal closing. Kind of the whole point of it in fact

I got a pretty good handle on it when building out a datacenter's RHEL 8 base image and playbook, because I used tmux as the default SSH "shell" due to our usecase.

But one of the things I encountered was that when tmux sessions are terminated-- which can happen in a number of ways-- vim will leave behind garbage files. Likewise, you can run into issues with the file being held open if others try to edit it at the same time (obviously).

This is why i keep saying it's an anti-pattern. Vim is fantastic as a personal text editor. It is a horrible use-pattern in an automation-heavy environment; you should be applying file changes via a CM tool most of the time, or at least identifying an atomic way to make the change. And powershell is pretty much designed for automation and scripting, not for your "lets edit some of my personal files" use-case.

There is no equivalent for powershell, pssession (or any other tool in Windows) that can allow a restoration of a previously suspended or backgrounded Vim session (or any other cli, tui program).

There's also no equivalent in python or ansible: because that's antithetical to their design paradigm. You might as well get angry trying to put nails in with an impact driver, and thereby conclude that hammers are superior.

Exactly. I am not sure why one of you guys recommended it to me (obviously its functionality was unknown by whoever did). Windows does not have a powerful enough command line setup to allow for such things.

And dewalt does not have a powerful enough manufacturing capability to put nails into a block of wood! Dewalt is pretty terrible, just like Windows, and for precisely the same reasons. When will they learn that hammers are a superior tool?

Barely. Why would there be more? What sort of crap do you think would be in a skel profile file?

I like how you neglected the far-more-populated .bashrc. It would have been awfully inconvenient for your "default profiles should be empty" claim if you had linked to something like this. Oh no! Theres all sorts of stuff in there! Upgrades will break it! What if one of those shell commands goes away?!?!?!

[coder]

But one of the things I encountered was that when tmux sessions are terminated-- which can happen in a number of ways-- vim will leave behind garbage files.

In my experience, recent versions of VIM don't leave these if they're not still running and you don't have any unsaved modifications. I'm not sure if what changed was a distro default, as opposed to anything internal to VIM.

In any case, if VIM is still running, it will even tell you the PID when you try to open that file. Then you can simply kill the existing process and recover your unsaved changes, if you had any.

Likewise, you can run into issues with the file being held open if others try to edit it at the same time (obviously).

If you've got the file open in another editing session, you probably don't want to open it anyway, but at least you have the option to do so. It's not like on Windows, where programs frequently open files exclusively and block any other accesses to them.

This is why i keep saying it's an anti-pattern.

The behavior I described isn't. If that's what you're running into, then you just have to take the time to read what it's telling you, when you try to re-open that file.

IMO, it's doing exactly what it should.

And powershell is pretty much designed for automation and scripting, not for your "lets edit some of my personal files" use-case.

Here's the thing I don't get about what you guys are saying. If I'm going to use a shell for scripting, I want to use it interactively also. That way, I can learn what I use from one context to benefit the other. I have no interest in using one shell for automation tasks and another for interactive use.

I think it's awesome to be able to interactively run some commands, and then copy them out of my history and into a script that I can tidy up and use to repeat the same steps I just did. Or, going the other way, to copy a few lines out of a script and run them interactively. I love that duality of shell scripting and it's why I'm even willing to overlook some warts & limitations of the shell as a programming language.

[ll1025]

I'm going to be frank; I really do not understand the use-case where you are in a tmux session, open vim, and suddenly decide you need to disconnect. That seems like it is begging for headaches. You mention vim with no unsaved changes: then who actually cares about resuming the vim session? What's the point?

Screen and tmux tend to shine in situations where you have long-running jobs that you do not want killed, not as a way to have unsaved work in an open document. The only time I could see needing something like this is with intermittent network-- and powershell works just fine in such situations, because a disconnect doesnt result in your shell automatically dying.

Dev tools have moved away from a centralized paradigm where you might need to be logged into the remote server where the file you're editing exists; there are just better ways of doing this, and so allowing a remote text editor to be backgrounded and disconnected for later resumption simply isn't a thing I think any powershell user cares about.

There are times I wish powershell had a ctrl+z capability-- such as with long-running queries-- but it's a trivial complaint especially in the context of Terminal where you can just spawn a new shell (or just get good: utilize jobs for long-running queries).

If that's what you're running into, then you just have to take the time to read what it's telling you

You're missing it. If you have a vim scratch file, and then a CM tool swaps that file out from underneath, and then you try to resume with the vim session restore, what's going to happen?

Keeping files open in vim in a CM'd environment is asking for pain.

Here's the thing I don't get about what you guys are saying. If I'm going to use a shell for scripting, I want to use it interactively also.

That is perfectly fine, but it seems like the argument is, "Powershell doesnt do X; bash does X; ergo Powershell is crap". Python doesn't do many of these things either but only the most hardcore of Bash zealots would call Python bad for that reason.

Would it be nice if Powershell had a killer interactive text editor and the ability to bg jobs? Sure, but nearly any time I am dealing with files where get-content is insufficient, I'm going to want Notepad++, VSCode, or Sublime over vim, any day of the week. I would honestly rather that effort go into more modules and Terminal improvements than into those things; if I need vim, I'm probably on a linux system with vim, and that rare occasion where I need to abort session mid-vim I can just come back later: as you note, Vim will pick up where we left off.

I don't get the complaint: everyone agrees that vim will allow that resumption via its scratch file, so who actually cares? Is the contention really that having to type "history !!" to reenter vim is what separates the good shells from the crap ones?

I think it's awesome to be able to interactively run some commands, and then copy them out of my history and into a script

And I think it's awesome to be able to seamlessly pass input and output between commands without screwing with cut and sed and awk scripts. I use export-excel all of the time, it's fantastic to be able to turn IT infra data into a report for my bosses' boss with a single command because everything is an object which translates perfectly into rows and columns.

Powershell has a LOT to offer if you give it a chance, but that involves understanding what it is and is not designed for. A lot of bashisms simply do not translate over, because they're not the same usecase.

[coder]

I'm going to be frank; I really do not understand the use-case where you are in a tmux session, open vim, and suddenly decide you need to disconnect.

In my case, it would be a remote login from home (i.e. over VPN) or transatlantic, and the ssh connection gets dropped.

That seems like it is begging for headaches. You mention vim with no unsaved changes: then who actually cares about resuming the vim session? What's the point?

If I'm editing a file and periodically saving it, then sometimes it's not going to have unsaved changes. I'm not going to exit the editor, every time I save it. Maybe I'm editing a script and I want to try running it in another window or tab.

powershell works just fine in such situations, because a disconnect doesnt result in your shell automatically dying.

I can't comment on that, because I'm talking about using VIM in a Linux environment. I have nothing to say about powershell, because I've simply not had occasion to use it. I was glad when I heard MS finally decided to replace the old shell and its crufty batch files.

Dev tools have moved away from a centralized paradigm where you might need to be logged into the remote server where the file you're editing exists; there are just better ways of doing this,

There are pragmatic reasons that still happens. You may think of everything from a large-scale enterprise mindset, but sometimes machines and embedded devices aren't deployed that way. I'm a developer, not an admin, and I deal with various embedded devices and appliances. My purposes for accessing them mostly involves testing, debugging, troubleshooting, etc. My remote sessions typically consist of a mix of running gdb, combing through logfiles, and running a wide variety of interactive commands.

There are times I wish powershell had a ctrl+z capability-- such as with long-running queries-- but it's a trivial complaint especially in the context of Terminal where you can just spawn a new shell (or just get good: utilize jobs for long-running queries).

Well, it's not trivial if I have to open a new connection in the new tab. Mine is typically not a situation where I have ssh keys setup, because I'm accessing a bunch of different devices and machines and they often get re-imaged. In fact, I don't know how many even have ~/ that's not a ramdisk.

You're missing it. If you have a vim scratch file, and then a CM tool swaps that file out from underneath, and then you try to resume with the vim session restore, what's going to happen?

Keeping files open in vim in a CM'd environment is asking for pain.

If I were using a CM tool that could change it out from under me, then I think I'd probably take a different approach to modifying it, so that my changes didn't randomly get clobbered.

About a decade ago, I was once in a situation where a departed sysadmin had some CM infrastructure I didn't know about, and it was clobbering my hand-edited changes to a config file on an infrastructure machine. Didn't take me too long to figure out what was going on, but then trying to grok his CM infrastructure was a slightly bigger undertaking.

That is perfectly fine, but it seems like the argument is, "Powershell doesnt do X; bash does X; ergo Powershell is crap".

I'm not trying to pile on. My comments are not meant to reinforce others' complaints and allegations, but just to offer my own perspective.

Python doesn't do many of these things either but only the most hardcore of Bash zealots would call Python bad for that reason.

I don't use Python the same way I use bash. I tend to use Python when a script outgrows the level of complexity I'm comfortable having in a bash script, so I tend not to look at it in the same way.

Would it be nice if Powershell had a killer interactive text editor and the ability to bg jobs?

Yeah, I'm a big fan of bash's builtin vi editing mode (set -o vi). Lots of other things use libreadline, as well, which means you can get the same capabilities by setting up your .inputrc .

Sure, but nearly any time I am dealing with files where get-content is insufficient, I'm going to want Notepad++, VSCode, or Sublime over vim, any day of the week.

I don't love vim, but I do like vi's conceptual approach to editing. I just wish the commands were more consistent in their behavior.

I don't get the complaint: everyone agrees that vim will allow that resumption via its scratch file, so who actually cares?

You lost me. VIM's autosave feature has saved my bacon countless times, when connections were dropped, machines crashed, etc. I do not use it to intentionally kill & resume editing sessions, however.

Powershell has a LOT to offer if you give it a chance, but that involves understanding what it is and is not designed for.

Yes, that's why I'm still reading. Even if I never use it, I don't mind hearing about what it does well (and poorly) and what people do/don't like about it.

BTW, thanks for posting. I've found this thread interesting and educational, on both sides. I just wish we could turn down the temperature and cut the abuse.

[ll1025]

I can't comment on that, because I'm talking about using VIM in a Linux environment. I have nothing to say about powershell, because I've simply not had occasion to use it. I was glad when I heard MS finally decided to replace the old shell and its crufty batch files.

You can imagine my frustration that the commenters in this thread who have been arguing about Powershell's suitability have self-admittedly not used or had very little experience with Powershell.

No one is trying to take your bash, tmux, or vim from you. And Powershell does not want to replace bash: if you're silly enough to set pwsh as your default shell on CentOS, you deserve all of the pain it will cause.

But everyone here calling it a bad shell is coming across as someone calling python a toy language. Professionals everywhere use these tools, and it's not because they're bad at their job or have never used a nix system. Many of the powershell pros I've known are OS polyglots who can make themselves at home on whatever you give them.

I'm a developer, not an admin

Then yes, you will find that powershell is an odd beast with little to attract you to it. For what you do, either bash or python will be better fits-- I cannot think of a situation where I would recommend a dev to use powershell where a python sdk would not be better.

But it (and MS Terminal) aren't for you. Theyre for the infra guys. This is why we aren't seeing eye to eye on vim replacement: to me, if a text file needs editing, that means theres a config I'm changing. And changing a single config file by hand, in my world, means I now have undocumented and unmanaged changes in my environment. Instead I would figure a change out using anything to dump the file, edit it offline, figure out either an in-line change or create a playbook to replace the entire file, and test it by running the CM tool against the one node. For infra guys like me, there's no such thing as "lets just edit this one file in vim". Even if its a single server you need to create a definition for the new server state that can be parsed by your CM tool.

Sorry for "abuse"-- was not my intention.

[dragon321]

*nod* Was he one of the people who was quoted in or contributed to The UNIX-HATERS Handbook or did I just read that quote around the same time I read UHH?

Either way, that particular "everything is a bag of bytes" complaint slammed face-first into "So, Mr. Mac developer, you used the beautiful Data Fork/Resource Fork system as intended... now how do you exchange files with PC users with minimal inconvenience? ...and if you're a developer and you need to carry along an implementation of the metaformat parser/serializer for the lowest-common denominator platform you want to support anyway, why not bundle the same code with all your ports rather than relying on an OS-proprietary thing?"

Well, he wasn't big fan of Unix and was pretty important person so I guess his quote could land in UNIX-HATERS Handbook.

You're right here. Unix IO is more complicated than "Hey let's read some bytes". Also nothing stops some developer to provide some library that will do the thing for you with nice function. macOS is example how Unix can be covered with nice GUI and API. I guess that would work as well for Windows NT.

[coder]

You're right here. Unix IO is more complicated than "Hey let's read some bytes". Also nothing stops some developer to provide some library that will do the thing for you with nice function. macOS is example how Unix can be covered with nice GUI and API. I guess that would work as well for Windows NT.

I can understand some distaste for parsing a bunch of ad hoc file formats from stuff like /etc/ or /proc/. Not only that, but just the overhead of parsing stuff, especially given the CPUs they had back in the days when Windows NT was first conceived, must've seemed like a lot of wasted cycles (80386 @ 25 MHz was pretty much top of the line).

Back when XML was trending (so, around 2000 or so), I had the idea that it'd be neat if everything had a XML serialization. You could have a duality between the binary in-memory C structs and streams, which would make the parsing and serialization much more seamless. There are definite benefits from having serializations of everything, for instance in remote admin or making snapshots and diffing rich, binary structures. And in the realm of UIs, the power of serialization is that much greater, as we've now seen by generations of HTML-based and stylesheet-driven GUIs.

I think the LISP folks sort of had this. A few years later, I got to know a crufty LISP hacker would wax about Symbolics and how everything was serializable as S-expressions. BTW, he claimed the company got sunk by a bad realestate deal -- nothing to do with their technology. That, and they stayed on proprietary hardware too long, when they should've just run their OS on mass market RISC CPUs.

[ssokolow]

I can understand some distaste for parsing a bunch of ad hoc file formats from stuff like /etc/ or /proc/. Not only that, but just the overhead of parsing stuff, especially given the CPUs they had back in the days when Windows NT was first conceived, must've seemed like a lot of wasted cycles (80386 @ 25 MHz was pretty much top of the line).

Not to mention how, even with those efforts, NT was still very demanding on resources compared to Windows 9x, which was demanding compared to Windows 3.1x. (I remember comfortably running Windows 3.1 on a 386 with 2MiB of RAM, while Windows 95 listed 4MiB in the minimum system requirements (8MB recommended if you weren't going to be building a "single-tasking dedicated workstation") and 16 MB was recommended for NT 3.1.)