The output that is displayed and the path of folder has no gap (the output javed and path PS... Both are attached. I want to display output "Maha Javed" to appear at one line and then PS.... To display on new line), how can I make the path to display on new line in terminal powershell in visual studio code?
It sounds like your prompt may be broken, the Prompt function is used in Powershell to generate the prompt.
In my case running this in VSC yeilds:
( Get-Command Prompt).ScriptBlock
"PS $($executionContext.SessionState.Path.CurrentLocation)$('>' * ($nestedPromptLevel + 1)) ";
# .Link
# https://go.microsoft.com/fwlink/?LinkID=225750
# .ExternalHelp System.Management.Automation.dll-help.xml
Now as the other commentors have noted this behaviour is not usual. But if your prompt script is different from the above for some reason you can reset it or at least see what it is and indeed change it to what you please.
See https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_prompts?view=powershell-7 for a full explanation of this.
( Get-Command Prompt).ScriptBlock
same problem what to do in ubuntu 20
How to display path in new line after displaying output in vs code in linux distro
Related
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 -
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.
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.
I'm using VScode for running my same powershell script with different parameters in different powershell.
Is there any way I can name the terminal title through powershell script so that I can differentiate for what parameters I've run in which terminal ?
Instead of 1:PowerShell and 2:PowerShell I need alpha and beta from parameteres of powershell,
I've checked this answer Change Integrated Terminal title in vscode, but it requires manual intervention.
The numbers will remain but you can change the title by first opening command palette (Ctrl + Shift + P) and then search for Terminal: Rename.
Then you can type whatever name you want to give.
I have a executable that when double clicked opens in a command line window.
Now there is a input file (i.e named "sphere_15000.inp") in the same directory where the executable apame_win64.exe is located. So we can inter the file name in the command line.
The question is how this can be done from mathematica front end? With the RunThrough command I tried to do it with no avail.
RunThrough["Executable Location", "sphere_15000"]
Do I need to put this file location in my Windows 7 environment path variable? Hope for some suggestion in this regard.
UPDATE
Found a solution to my problem.
First set the Mathematica directory to the folder where the executable is located.
path="C:\Users\FlowCrusher\Desktop\CUSP solver\Apame_build_2011_01_09\solver";
SetDirectory[path];
Then use the following style of input.
Run["\"\"apame_win64.exe\" \"input\"\""]
Here "apame_win64.exe" is the executable one want to run and "input" is the input file for the executable. This solves the problem. But a new item in the wishlist.
Is there a way to hide the console window in the background?
Here is how it looks on my screen.
As Chris suggested if we use minimized console in the Run command we get a minimized window but the program does not execute.
I hope that a solution exists.
BR
Yes, you might put the folder of you executable into the Path variable, or provide the full path name.
However, RunThrough seems to have been superseeded (on Windows) by
Import["!command ","Text"], which will execute command and read the comaand line output into Matheamtica as a string.
E.g.:
Export["testit.txt", "bla", "Text"];
Import["!dir" <> " testit* > dir.log", "Text"];
FilePrint["dir.log"]
--
Otherwise, I also had good results in the past using NETLink (not sure if WScript.shell
still works on Windows7/8 or if one should use something else).
Emulating Run (RunThrough is not really needed I think):
Run2[cmd_String] := Module[{shell},
Switch[$OperatingSystem,
"Windows",
Needs["NETLink`"];
shell = NETLink`CreateCOMObject["WScript.shell"];
shell # run[cmd,0,True],
"Unix",
Run # cmd,
"MacOSX",
Run # cmd ] ];
Can you run your application with input from a basic command window instead of the application console? This might be the form of command you would need:
apame_win64 -input sphere_15000.inp
or simply
apame_win64 sphere_15000.inp
You can probably check the available switches by running apame_win64 -help
A multi-part command can be run from Mathematica, e.g.
Run["type c:\\temp\\test.txt"]
Alternatively, also returning output to the Mathematica session:
ReadList["!type c:\\temp\\test.txt", String]
I landed here wanting to run abaqus command line on windows.
The solutions provided here worked out for me (Windows 7, Mathematica 9):
SetDirectory#path;
Run["start /min abaqus job=" <> fileName <> " interactive ask_delete=OFF >> log.txt"]
(Here the abaqus option ask_delete=OFF overwrites an existing simulation results and the >> redirects all the output to a file)
I think, minimizing the window did not run in your case since the executable throws open that window. In that case, this might be of some help