I see this come up from time to time, and I’m not honestly sure why, because I don’t actually think there’s any reason to use a console editor on Windows in the first place.
On Unix, you perform ad hoc administration by logging into the remote system and doing your work there. In this context, console editors make a ton of sense, because the only way to edit files on the remote system will be to launch an editor running on that system. (Yeah, I know about Emacs TRAMP mode and sshfs, but those are neither the traditional way to do those things, nor common, and both have major caveats and drawbacks compared to the log-on-directly-and-change-stuff approach.)
But in the Windows world, while you can do that (via e.g. RDC), you’re working against the grain. Instead, your boxes should be bound to an ActiveDirectory controller, which lets you administer remote systems directly from your own box by using SMB and DCOM (or its more modern variants, like WinRM). In this environment, you don’t need a console editor; you can just use whatever editor prefer locally, complete with all of your local settings and overrides and what have you, and edit the remote files directly over SMB. (This also avoids whole classes of things that can be tricky to get right in Unix, like syncing dotfiles, managing multiple clipboards, and so on.)
I’m thus continually perplexed by this. I don’t know whether I’ve just been lucky in working exclusively in shops with properly configured Windows networks, and thus I have an unrealistically good experience here; or whether Microsoft just does a really poor job teaching Unix gurus how Windows best practices differ from Unix’s.
Maybe the Windows way is better, and maybe it isn’t, but it’s certainly sufficiently different that you’re going to have
a bad time trying to treat them as if they’re the same—and trying to use console editors via remote PowerShell sessions just seems unnecessarily painful to me.
I see this come up from time to time, and I’m not honestly sure why, because I don’t actually think there’s any reason to use a console editor on Windows in the first place.
On Unix, you perform ad hoc administration by logging into the remote system and doing your work there. In this context, console editors make a ton of sense, because the only way to edit files on the remote system will be to launch an editor running on that system. (Yeah, I know about Emacs TRAMP mode and sshfs, but those are neither the traditional way to do those things, nor common, and both have major caveats and drawbacks compared to the log-on-directly-and-change-stuff approach.)
But in the Windows world, while you can do that (via e.g. RDC), you’re working against the grain. Instead, your boxes should be bound to an ActiveDirectory controller, which lets you administer remote systems directly from your own box by using SMB and DCOM (or its more modern variants, like WinRM). In this environment, you don’t need a console editor; you can just use whatever editor prefer locally, complete with all of your local settings and overrides and what have you, and edit the remote files directly over SMB. (This also avoids whole classes of things that can be tricky to get right in Unix, like syncing dotfiles, managing multiple clipboards, and so on.)
I’m thus continually perplexed by this. I don’t know whether I’ve just been lucky in working exclusively in shops with properly configured Windows networks, and thus I have an unrealistically good experience here; or whether Microsoft just does a really poor job teaching Unix gurus how Windows best practices differ from Unix’s.
Maybe the Windows way is better, and maybe it isn’t, but it’s certainly sufficiently different that you’re going to have a bad time trying to treat them as if they’re the same—and trying to use console editors via remote PowerShell sessions just seems unnecessarily painful to me.
updated
nice to see aurora get a shout out - it was by far my favourite dos-era text editor, and i’m really sad it died the way it did.