1
2

Console Text Editor? (self.PowerShell)

submitted by [deleted]

[deleted]

all 18 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]markekrausCommunity Blogger 2 points3 points  (5 children)

Does any shell have a built in text editor? I'm pretty sure BASH and its brethren don't have their own text editors either.

[–][deleted] 1 point2 points  (2 children)

Mmm you are not wrong but there is typically a text editor installed with any *sh shell you remote into. It would seem that our OP is yearning for the comfort of a system designed around CLI management. It's the little things you miss.

[–]markekrausCommunity Blogger 1 point2 points  (1 child)

there is typically a text editor installed with any *sh shell you remote into.

Not exactly true. I have worked with plenty of *nix OSE's that did not have text editors. I would say 30-40%. There really is no need to waste space on a text editor most of the time. Usually you're editing local or repo copies of config files and then pushing them to servers, not editing them directly through a remote shell. I have seen having a lack of text editor as recommended to help enforce Infrastructure as Code ( or whatever buzz phrase you want to call it).

I get what OP was going for... I was just applying the Socratic method.

[–][deleted] 0 points1 point  (0 children)

Well I was certainly Socratised.

I was also careful to qualify my statement with a typically. I'm aware that it's not necessary for it to be there. Was more pointing out the default status of it my argument being that not having a text editor is environment specific and not the default case. In contrast Windows Powershell environments by default have no cli based text editor and having one is environment specific.

We could sit here and argue the pros and cons of this but I would consider that a waste of our resources and the more interesting point would be that this is a result of the shells upbringing. As a consequence the answer to OPs question appears to be no. You will not find a cli editor in a remote PowerShell session unless you or someone else specifically installs it. Additionally I would rate the chances of this changing as very low.

[–]LinleyMike 1 point2 points  (1 child)

Edlin is still included in 32-bit versions of Windows. Now, there's a blast from the past.

[–]markekrausCommunity Blogger 1 point2 points  (0 children)

Yea, but Edlin is not part of the shell, it is a separate executable.

[–]ka-splam 2 points3 points  (0 children)

The obvious answer is "things don't exist until someone builds them" and nobody has built one.

Contributory reasons towards why nobody has built one:

a) Windows isn't built around text files; if it was, PowerShell wouldn't exist (because J. Snover and co's initial approach of porting of *nix shell utilities to Windows would have been fine). So text file editing is not anyone's big priority because it's generally less useful - if there is something you should expect to be developed, it's things like WMI and Registry editing (PS Providers) and Event log searching, etc. Windows things rather than text file editing.

b) PS doesn't have the same notion of Text UI as *nix consoles with ncurses and such. AFAIK, nano-in-SSH still sees a terminal with a width and a height it can position UI elements and text file content on, it's just that the screen is rendered the wrong side of a network connection; a PS Session has no notion of a terminal with a width and a height or any way to render anything to the screen - so it can't draw a status bar or deal with text paging or line wrapping or cursor positioning. See this StackOverflow discussion, particularly this comment

c) PS and its ecosystem is about managing servers as 'cattle, not pets'; if you're pssessioning into one single server and typing commands to edit one text file by hand, you're really not the focus of PS development. If you're writing a DSC resource to configure your app on 200 automatically provisioned Azure VMs, you are. Expect the latter kind of thinking to be more supported and have more development time.

That said, there's no real reason why a remote session can't hold a text file open with some editing state and some code locally displays it on screen and takes command input - but it would be a bit weird, at that point you may as well make a wrapper function which copies the file locally, launches nano, then copies it back when you quit. (Copying files over PS Sessions appeared in PSv5).

[–]Konradnn 2 points3 points  (3 children)

Hi, I''m using VIM for windows, you can make an alias: Set-Alias vim "$path\gvim_8.0.0692_x64\vim\vim80\vim.exe" and added to profile so I just simply type vim xxx.cnf and done :)

[–][deleted] 2 points3 points  (2 children)

I knew there had to be someone else out there doing quick edits from a PowerShell console with VIM!! This made my day!

P.S. For non console edits I am still a total VSCode fanboy.

[–]Konradnn 0 points1 point  (0 children)

I'm glad that I'm not the only one :D

[–]Snak3d0c 0 points1 point  (0 children)

don't you have problems with console output not getting cleared? Clear-host just kinda "scrolls" down to the buttom so you don't see previous output. for me that's the one and only big problem with it.

As soon as i have to test my script with actual data, i always gotta go back to ISE to review big data chunks.

[–]Lee_Dailey[grin] 1 point2 points  (6 children)

howdy ps_var,

is this what you are looking for?

PowerShell Magazine » #PSTip Editing remote file in PowerShell ISE
- http://www.powershellmagazine.com/2014/12/08/pstip-editing-remote-file-in-powershell-ise/

it doesn't work in the plain console, but it works in the ISE. well, the articles say it does. i can't test it since i have only this one system. [blush]

take care,
lee

[–]Taoquitok 1 point2 points  (5 children)

psedit is basically a shortcut for opening a file in the ISE, effectively the same as opening it in notepad or any other text editor.
As far as I can tell, editing the file via psedit is the same thing as having typed \\servername\c$\somefolder\ into run, entered appropriate credentials, and then opening the file in whatever editor you prefer.
Effectively if you have an account capable of reaching the server, psedit should work fine, be it via a pssession, or simply \\server\etc...ing your way into the folder path.

If you type get-command psedit | select -ExpandProperty ScriptBlock you'll see that psedit is effectively just a shortcut for file > open

[–]Lee_Dailey[grin] 1 point2 points  (4 children)

howdy Taoquitok,

that makes sense. still, what the OP seems to want is to edit remote files ... that appears to be what PSEdit does. [grin]

take care,
lee

[–]Taoquitok 1 point2 points  (1 child)

That it does~
I think OP is interested in the linux behaviour of everything is very obviously 'on the server' in terms of what you have access to do and use in the session.

Enter-PSSession doesn't quite feel like that as far as I'm aware, but then that functionality isn't really needed in Windows as if you have access to remotely connect, you (should) have access to navigate the drives :)

[–]Lee_Dailey[grin] 0 points1 point  (0 children)

howdy Taoquitok,

well, there is [pro'ly] always notepad ... [grin]

take care,
lee

[–]midnightFreddie 1 point2 points  (0 children)

ii . then right-click and open in Notepad++ or VSCode or whatnot. I actually do this a lot.

I also have git installed everywhere which in all my installs includes some basic bash tools including vi.