How to open a file from the integrated terminal in VSCode to a new tab - powershell

If my script is run within vscode, it want it to open a .txt file in a new tab in vscode. Else, open the folder containing the file. However, the current "code" command opens it in the terminal window instead of a new edit tab.
if ($env:TERM_PROGRAM -eq 'vscode') {
code 'C:\temp\_Release_Evidence\test.txt'
}
else {
explorer 'C:\temp\_Release_Evidence'
}

Normally, code refers Visual Studio Code's CLI, which is assumed to be in one of the directories listed in $env:PATH:
On Windows, it refers to the code.cmd batch file that serves as the CLI entry point.
On Unix-like platforms it refers to a code Bash script.
Its default behavior is to open a given file as a new tab in the most recently activated Visual Studio Code window (which, when run from inside Visual Studio Code, is by definition the current window).
If that doesn't happen for you, perhaps code refers to a different executable on your machine:
To avoid ambiguity, use the full CLI path instead, which, however, requires you to know Visual Studio Code's install location; typical CLI locations are:
Windows: $env:LOCALAPPDATA\Programs\Microsoft VS Code\bin\code.cmd
macOS: /usr/local/bin/code
Linux: /usr/bin/code
On Windows, something as simple as including the filename extension in the invocation - i.e., code.cmd - may help.
However, assuming you're using the PIC (PowerShell Integrated Console), a specialized PowerShell shell that comes with the PowerShell extension for Visual Studio Code, a workaround that also performs better, because it doesn't require launching a child process:
The PIC comes with the psedit command (an alias for the Open-EditorFile function), which quickly opens one or more files in a tab in the current Visual Studio Code window.
Caveat: As of version v2022.5.1 of the PIC, specifying multiple files only works meaningfully if they are individually enumerated, as literal paths. If you try to use a wildcard pattern or a directory path, all matching files / files in the directory are uselessly opened in sequence in a single tab.
Thus, you could use the following:
if ($env:TERM_PROGRAM -eq 'vscode') {
# Use `psedit`, if available; `code` otherwise.
$exe = if ((Get-Command -ErrorAction Ignore psedit)) { 'psedit' } else { 'code' }
& $exe 'C:\temp\_Release_Evidence\test.txt'
}
else {
explorer 'C:\temp\_Release_Evidence'
}

I can't reproduce this or explain why this might occur on your system. Running the following whether in the PowerShell Integrated Terminal (which #mklement0 explained succinctly) or a standard PowerShell terminal in VS Code's Terminal pane should open the file in a new tab where file contents are normally displayed:
code /path/to/file.txt
A suitable workaround may be to get the contents of a text file and pipe them in via STDIN. We can do this by adding a hyphen - as an empty parameter to code when piping data to it:
# Tip: Use the gc alias for Get-Content
Get-Content /path/to/file.txt | code -
You can then use Save As... to save the file to its intended target once you make your changes. You will need to use Ctrl+C in the terminal to close the input stream if you need to run additional commands before closing the file or saving to a one.
Even if this isn't a suitable workaround for you, it's a handy tip in other scenarios. For example, the following command will open documentation for Get-Process inside VSCode:
Reminder: Don't forget to hit Ctrl+C in the terminal once the content finishes populating to be able to run additional commands, or close the temporary file buffer.
Get-Help Get-Process -Detailed | code -

Related

PowerShell command to set Visual Studio to Run as Administrator

I have been assigned the job of automating a long list of tasks for developers to load into Intune.
One of the tasks is to set the Run As Administrator feature to Visual Studio with a script.
I know you can right-click on the exe, go to properties > Advanced and set that setting, but I'm struggling to find a scriptable way to do that. Any suggestions would be appreciated.
Edit: This to update the shortcut to send the command to run as administrator.
The shell-friendly way to create shortcut files (*.lnk) unfortunately does not provide a way to mark a shortcut file as needing to run with elevation (as administrator).
To do so, you have two options:
A quick-and-dirty solution based on raw byte manipulation of a .lnk file.
The caveat is that such an approach may break in a future Windows version, should the binary file format of shortcut file changes. See below.
A proper solution via the appropriate COM interfaces, which are not script-friendly, however.
See this blog post for C++ sample code.
Quick-and-dirty solution, effective as of Windows 10, gratefully adapted from this answer:
# Get the *full path* of the target shortcut file (*.lnk),
# using sample path ~/Desktop/test.lnk here.
$shortcutFile = Convert-Path -LiteralPath (Get-Item ~/Desktop/test.lnk)
# Read the shortcut file's raw byte contents.
$bytes = [System.IO.File]::ReadAllBytes($shortcutFile)
# Set the relevant byte to mark the shortcut as needing to
# run with elevation.
$bytes[21] = 34
# Save the modified byte array back to the original file.
[System.IO.File]::WriteAllBytes($shortCutLocation, $bytes)

How do you edit the command line in an external editor?

tl;dr
I want to find a Powershell version of the bash edit-and-execute-command widget or the zsh edit-command-line widget.
Background
Short commands get executed directly on the command-line, long complicated commands get executed from scripts. However, before they become "long", it helps to be able to test medium length commands on the command-line. To assist in this effort, editing the command in an external editor becomes very helpful. AFAIK Powershell does not support this natively as e.g. bash and zsh do.
My current attempt
I am new to Powershell, so I'm bound to make many mistakes, but I have come up with a working solution using the features of the [Microsoft.Powershell.PSConsoleReadLine] class. I am able to copy the current command-line to a file, edit the file, and then re-inject the edited version back into the command-line:
Set-PSReadLineKeyHandler -Chord "Alt+e" -ScriptBlock {
$CurrentInput = $null
# Copy current command-line input, save it to a file and clear it
[Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref] $CurrentInput, [ref] $null)
Set-Content -Path "C:\Temp\ps_${PID}.txt" -Value "$CurrentInput"
[Microsoft.PowerShell.PSConsoleReadLine]::KillRegion()
# Edit the command with gvim
Start-Job -Name EditCMD -ScriptBlock { gvim "C:\Temp\ps_${Using:PID}.txt" }
Wait-Job -Name EditCMD
# Get command back from file the temporary file and insert it into the command-line
$NewInput = (Get-Content -Path "C:\Temp\ps_${PID}.txt") -join "`n"
[Microsoft.PowerShell.PSConsoleReadLine]::Insert($NewInput)
}
Questions
My current solution feels clunky and a somewhat fragile.
Are there other solutions? Can the current solution be improved?
Environment
OS Windows 10.0.19043.0
Powershell version 5.1.19041.1320
PSReadLine version 2.0.0
The solution I went with
Create a "baked" executable similar to what mklement0 showed. I prefer vim for this instead of `gvim, as it runs directly in the console:
'#vim -f %*' > psvim.cmd
$env:EDITOR = "psvim"
Set-PSReadLineKeyHandler -Chord "Alt+e" -Function ViEditVisually
tl;dr
PSReadLine comes with the feature you're looking for, namely the ViEditVisually function, and on Unix-like platforms it even has a default key binding.
For the feature to work, you need to set $env:VISUAL or $env:EDITOR to the name / path of your editor executable.
As of PSReadLine v2.1, if you also need to include options for your editor - such as -f for gvim - you need to create a helper executable that has the options "baked in".
Since creating a helper executable is cumbersome, a custom emulation of the feature, as you have attempted and as refined in zett42's helpful answer, may be the simpler solution for now. zett42's answer additionally links to a Gist that improves the original functionality by preserving cursor positions.
GitHub issue #3214 suggests adding support for recognizing executables plus their options in these environment variables.
Details below.
The PSReadLine module ships with such a feature, namely the ViEditVisually function.
Its default key bindings, if any, depend on PSReadLine's edit mode, which you can set with Set-PSReadLineOption -EditMode <mode>:
Windows mode (default on Windows): not bound
Emacs mode (default on macOS and Linux): Ctrl-xCtrl-e
Vi mode: v in command mode (press Esc to enter it)
Use Set-PSReadLineKeyHandler to establish a custom key binding, analogous to the approach in the question; e.g., to bind Alt-e:
Set-PSReadLineKeyHandler -Chord Alt+e -Function ViEditVisually
For the function to work, you must define the editor executable to use, via either of the following environment variables, in order of precedence: $env:VISUAL or $env:EDITOR; if no (valid) editor is defined, a warning beep is emitted and no action is taken when the function is invoked.
E.g., to use the nano editor on macOS: $env:VISUAL = 'nano'
The value must refer to an executable file - either by full path or, more typically, by name only, in which case it must be located in a directory listed in $env:PATH
Note: .ps1 scripts do not qualify as executable files, but batch files on Windows and shebang-line-based shell scripts on Unix-like platforms do.
As of PSReadLine 2.1, including options for the executable - such as --newindow --wait for code (Visual Studio Code) is not supported.
Therefore, for now, if your editor of choice requires options, you need to create a helper executable that has these options "baked in"; see examples below.
GitHub issue #3214 proposed adding support for allowing to specify the editor executable plus options as the environment-variable value, which is something that Git (which recognizes the same variables) already supports; for instance, you could then define:
$env:VISUAL = 'code --new-window --wait'
Example configuration with a helper executable for code (Visual Studio Code):
Create a helper executable in the user's home directory in this example:
On Windows:
'#code --new-window --wait %*' > "$HOME\codewait.cmd"
On Unix-like platforms:
"#!/bin/sh`ncode --new-window --wait `"$#`"" > "$HOME/codewait"; chmod a+x "$HOME/codewait"
Add a definition of $env:VISUAL pointing to the helper executable to your $PROFILE file, along with defining a custom key binding, if desired:
$env:VISUAL = "$HOME/codewait"
# Custom key binding
Set-PSReadLineKeyHandler -Chord Alt+e -Function ViEditVisually
This code has some issues:
Temp path is hardcoded, it should use $env:temp or better yet [IO.Path]::GetTempPath() (for cross-platform compatibility).
After editing the line, it doesn't replace the whole line, only the text to the left of the cursor. As noted by mklement0, we can simply replace the existing buffer instead of erasing it, which fixes the problem.
When using the right parameters for the editor, it is not required to create a job to wait for it. For VSCode this is --wait (-w) and for gvim this is --nofork (-f), which prevents these processes to detach from the console process so the PowerShell code waits until the user has closed the editor.
The temporary file is not deleted after closing the editor.
Here is my attempt at fixing the code. I don't use gvim, so I tested it with VSCode code.exe. The code below contains a commented line for gvim too (confirmed working by the OP).
Set-PSReadLineKeyHandler -Chord "Alt+e" -ScriptBlock {
$CurrentInput = $null
# Copy current console line
[Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref] $CurrentInput, [ref] $null)
# Save current console line to temp file
$tempFilePath = Join-Path ([IO.Path]::GetTempPath()) "ps_$PID.ps1"
Set-Content $tempFilePath -Value $CurrentInput -Encoding utf8
# Edit the console line using VSCode
code --new-window --wait $tempFilePath
# Uncomment for using gvim editor instead
# gvim -f $tempFilePath
# The console doesn't like the CR character, so rejoin lines using LF only.
$editedInput = ((Get-Content -LiteralPath $tempFilePath) -join "`n").Trim()
# Replace current console line with the content of the temp file
[Microsoft.PowerShell.PSConsoleReadLine]::Replace(0, $currentInput.Length, $editedInput)
Remove-Item $tempFilePath
}
Update:
This GitHub Gist includes an updated version of the code. New features including saving/restoring the cursor position, passing the cursor position to VSCode and showing a message while the console is blocked.
Notes:
A default installation of VSCode adds the directory of the VSCode binaries to $env:PATH, which enables us to write just code to launch the editor.
While UTF-8 is the default encoding for cmdlets like Set-Content on PowerShell Core, for Windows PowerShell the parameter -Encoding utf8 is required to correctly save commands that contain Unicode characters. For Get-Content specifying the encoding isn't necessary, because Windows PowerShell adds a BOM which Get-Content detects and PowerShell Core defaults to UTF-8 again.
To have Alt+E always available when you open a console, just add this code to your $profile file. Makes quick testing and editing of small code samples a breeze.
VSCode settings - for most streamlined experience, enable "Auto Save: onWindowChange". Allows you to close the editor and save the file (update the console line) with a single press to Ctrl+W.

How do i hide file path information in VS-Code Terminal

I see this unnecessary file path information whenever I execute a program in the terminal section.
Is there a way to hide that file path?
This is not so much VSCode terminal related, rather it is more shell related (see What's the difference between Terminal, Console, Shell, and Command Line). Your VScode's terminal is running a shell internally, but a terminal is not much more than a display window that calls a shell's functions. So, in order to edit the prompt (which comes from the shell), we have to edit your shell config.
From your screenshot, it looks like the particular shell you're running is Powershell. Powershell has its own prompt that it generates each time before you run a command. It does so by calling the prompt() function (you can read more about it at Microsoft Docs).
Therefore, if you just want an empty prompt, then all you have to do is create an empty prompt function and add it to your powershell profile.
From your terminal, open your powershell profile file using VSCode (or any text editor)
# $profile is a variable in powershell
# that holds path of the powershell config
code $profile
Then add an empty prompt function into the profile
function prompt { }
Save the file and reopen another powershell instance in your VSCode terminal, and now it should look like this
PS>
If you're interested in further customizing this prompt, I would highly recommend looking into starship, a cross-platform shell prompt that can be used inside powershell. By default it's an even simpler arrow
❯
It only displays the most relevant paths, and can be customized to a much greater extent than the powershell prompt.

Visual Studio Code / powershell commands History up key

In what way could I log my previously entered commands in visual studio code?
For instance when I press up key I can up through all my previous commands,
I would like to log these to a file if possible.
Where are they stored locally?
Could I log it with something like node?
I've actually solved this myself thanks to the help of #bruce-payette and #robdy for pointing me in new directions. Logging all commands, also from previous sessions, can be done from PowerShell itself.
Enter this command in PowerShell to recieve the path to a file where PowerShell saves the history accessible by using the up key:
(Get-PSReadlineOption).HistorySavePath
This will output something like this:
C:\Users\[username]\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
Open this file to see all saved commands from previous sessions!
The cmdlet Get-History will give you the history of the commands you've run. You can save this to a file by doing
Get-History | Out-File myhistory.txt

Associate .pl with Perl.exe [duplicate]

I want my Perl scripts to behave just like any other executable (*.exe file).
When I double-click on myscript.pl I want it to execute instead of opening in a text editor.
I want to run myscript.pl instead of perl myscript.pl.
I really want to run myscript instead of myscript.pl.
I want to run program | myscript instead of program | perl myscript.pl.
I want to be able to run my script via drag & drop.
There are a number of changes you have to make on Windows to make all of
these things work. Users typically stumble upon things that don't work one at
a time; leaving them confused whether they've made an error, there's a bug in
Perl, there's a bug in Windows, or the behavior they want just isn't possible.
This question is intended to provide a single point of reference for making
everything work up front; ideally before these problems even occur.
Related questions:
How do I make Perl scripts recognize parameters in the Win32 cmd console?
Running a perl script on windows without extension
Perl execution from command line question
How can I read piped input in Perl on Windows?
Perl on Windows, file associations and I/O redirection
How do I create drag-and-drop Strawberry Perl programs?
Note: The actions below require administrative privileges. For
steps utilizing the command prompt it must be launched via "Run as
administrator" on Windows Vista / Windows 7.
Associate *.pl files with perl
Run the following commands at a shell prompt:
assoc .pl=PerlScript
ftype PerlScript=C:\bin\perl.exe "%1" %*
Replace C:\Perl\bin\perl.exe with the path to your Perl installation. This
enables you to run myscript.pl instead of perl myscript.pl.
Default install locations are:
ActivePerl: C:\Perl
Strawberry Perl: C:\Strawberry
Add .PL to your PATHEXT environment variable.
This makes Windows consider *.pl files to be executable when searching your
PATH. It enables you to run myscript instead of myscript.pl.
You can set it for the current cmd session
set PATHEXT=%PATHEXT%;.PL
To set it permanently (under Windows Vista or Windows 7)
setx PATHEXT %PATHEXT%;.PL
Under Windows XP you have to use the GUI:
Right-click My Computer, and then click Properties.
Click the Advanced tab.
Click Environment variables.
Select PATHEXT, then click Edit.
Append ;.PL to the current value.
Make I/O redirection work
I/O redirection (e.g. program | myscript) doesn't work for programs started
via a file association. There is a registry patch to correct the problem.
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Warning: In principle, this should only be necessary on Windows XP. In my experience it's also necessary in Windows 7. In Windows 10 this is actively harmful—programs execute but produce nothing on stdout/stderr. The registry key needs to be set to 0 instead of 1.
See also:
STDIN/STDOUT Redirection May Not Work If Started from a File Association
Perl Scripts on Windows 10 run from Explorer but not Command Prompt
If patching the registry isn't an option running program | perl -S myscript.pl
is a less annoying work-around for scripts in your PATH.
Add a drop handler
Adding a drop handler for Perl allows you to run a Perl script via drag & drop;
e.g. dragging a file over the file icon in Windows Explorer and dropping it
there. Run the following script to add the necessary entries to the registry:
use Win32::TieRegistry;
$Registry->Delimiter("/");
$perlKey = $Registry-> {"HKEY_CLASSES_ROOT/Perl/"};
$perlKey-> {"shellex/"} = {
"DropHandler/" => {
"/" => "{86C86720-42A0-1069-A2E8-08002B30309D}"
}};
Convert your perl scripts into batch files using pl2bat once they are ready to be run by users.
The trick works through the perl -x switch which, according to perldoc perlrun, makes Perl search for the first line looking like #!.*perl.
After following the instructions in the accepted answer, a double click still led to .pl files opening with Notepad in Windows 10 — even when perl.exe was set as the default file handler.
After finding Jack Wu's comment at ActivePerl. .pl files no longer execute but open in Notepad instead I was able to run perl scripts on double-click as such:
Select and right-click a .pl file
Use the "Open With" submenu to "Choose another app"
Select "Always use this app to open .pl files" (do this now – you won't get the chance after you have selected a program)
Scroll to the bottom of the "Other options" to find "More apps", and select "Look for another app on this PC"
Navigate to C:/path/to/perl/bin/ and select Perl5.16.3.exe (or the equivalent, depending on which version of Perl you have installed: but not Perl.exe)
Then the Perl icon appears next to .pl files and a double-click leads to them opening in Perl every time, as desired.
I tried the assoc and ftype methods and they didn't work for me.
What worked was editing this registry key:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command
It was set to:
"C:\Perl64\bin\perl.exe" "%1"
When it should be:
"C:\Perl64\bin\perl.exe" "%1" %*
It is the same content as the ftype, but for arcane windows reasons, I had to set it there too.
Like some others, I had set 'assoc' and 'ftype', but also had set Notepad text editor via the GUI, and when I tried to execute a script via the command line, Windows invoked Notepad to edit the script instead of running my script.
Using the GUI to instead point the .pl file association to the script-running executable was not much of an improvement, since it would invoke the executable on my script, but would pass no command-line arguments (even when I invoked my script from the command line).
I finally found salvation here which advised me to delete some registry keys.
Key quote:
"The problem is that if you have already associated the program with the extension via the Open With dialog then you will have created an application association, instead of a file extension association, between the two. And application associations take precedence."
In my case, following the instructions to use RegEdit to delete
HKEY_CLASSES_ROOT \ Applications \ perl.exe
where perl.exe is the name of my Perl executable, and then also deleting:
HKEY_CLASSES_ROOT \ .pl
seemed to solve my problem, and then (after re-executing 'assoc' and 'ftype' commands as shown in other answers) I could then execute scripts from cmd.exe and have them run with access to their command-line parameters.
Some other related information here.