I have a problem with VSCode terminal that started with the latest version.
It might be a bug or just a setting that I have missed, therefore I want to ask you before I report it as a bug.
Version 1.19.3
Commit 7c4205b5c6e52a53b81c69d2b2dc8a627abaa0ba
Date 2018-01-25T10:36:34.867Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
I have a file with different functions that I just for Office365 administrative tasks.
I always open the file in VSCode and run it (F5) and then I call the functions from another file.
But with the latest VSCode upgrade, when I run the file I get these errors in the terminal window. The errors point to lines that I have commented out (#).
In every function I first have commented lines with explanations to every variable that I use, like this: #$UserName = the Name of the user.
If I remove the $ sign after the comment-char # then the error for that line disappears.
The issue is not that I dont use the proper comment-based help syntax.
It is the fact that I have commented out variables that I don't use and that raises an error when I run (F5) the file in VSCode.
Does anyone have an explanation to why I can't have #$Var in my code.
At C:\Users\anno\OneDrive för företag\Powershell\Script\Anslut_till_O365.ps1:44 char:3
+ #$UPN: anvnamn & epostadress
+ ~~~~~
Variable reference is not valid. ':' was not followed by a valid variable name
character. Consider using ${} to delimit the name.
At C:\Users\anno\OneDrive för företag\Powershell\Script\Anslut_till_O365.ps1:45 char:3
+ #$Firstname: Förnamn
+ ~~~~~~~~~~~
Variable reference is not valid. ':' was not followed by a valid variable name
character. Consider using ${} to delimit the name.
At C:\Users\anno\OneDrive för företag\Powershell\Script\Anslut_till_O365.ps1:46 char:3
+ #$Lastname: Efternamn
+ ~~~~~~~~~~
Variable reference is not valid. ':' was not followed by a valid variable name
character. Consider using ${} to delimit the name.
At C:\Users\anno\OneDrive för företag\Powershell\Script\Anslut_till_O365.ps1:47 char:3
+ #$Title: Medlemsnr inkl filialnrâ,¬
+ ~~~~~~~
Variable reference is not valid. ':' was not followed by a valid variable name
character. Consider using ${} to delimit the name.
Below is the the first lines in the function that the Error is complaining about.
Function CreateNewE1User {
#$UPN: anvnamn & epostadress
#$Firstname: Förnamn
#$Lastname: Efternamn
#$Title: Medlemsnr inkl filialnrEUR
#$Displaynamn: Visningsnamn (Kedja Ort (Butiksnamn), Förnamn Efternamn KEDJA
#$PWD: Tillfälligt lösenord
#param ($UPN,$Firstname,$Lastname,$Title,$Displaynamn,$PWD,$SMTP)
Param(
$UPN,
$Firstname,
$Lastname,
$Title,
$Displaynamn,
$PWD='Password01'
)
#skapa ny användare
New-MsolUser -UserPrincipalName $UPN -FirstName $Firstname -LastName $Lastname -Title $Title -DisplayName $Displaynamn -UsageLocation "SE" -PasswordNeverExpires $false
}
Adding my comment as an answer since it did work out for the OP.
Have you thought that this is an environment thing?
Meaning something has changed/gotten corrupted on your system.
I say this because, I've seen this happen and it has happened to me. Code runs fine on one system and fails on another,
I have that issue as we speak. Do you have another system to try.
As a follow on to your issue and my associated comment. My discovery was that the latest VSCode update updated the default Keybindings, thus causing a conflict with my custom user keybindings. Once I deleted my custom keybindings which conflicted with the new default keybindings all things returned to normal.
Moral of the story, pay attention to the VSCode updates and really read the ReadMe file. Especially if you are in the habit of customizations.
The issue you are having is the PowerShellEditorService. This is the engine used by the PowerShell extension in VS Code and is what the PS Integrated Terminal is run on.
I cannot duplicate the errors you are getting. I am on the latest release of VS Code (1.19.3) and the PS Extension (1.5.1). If you update and still get the issue you can submit it to the GitHub repo to find out why it may be doing that on your installation. My guess is it still parses the line even if you have it commented. If you block comment that whole section it will likely cause the engine to skip trying to parse each line.
Related
I like to develop a script that modify a folder name when the lvl up folder name endings can changed .
ususully in ps im just using a wild card like this Something.*
but using this inside a reanme-item command does not works .
i am getting :
name-Item : Cannot process argument because the value of argument "path" is not valid. Change the value of the "path" argument and run the operation
again.
At line:1 char:1
Without examples of your code it's not completely clear what your usage is. There is a similar recent question/answer here that may help Powershell Changing Bulk File Extensions All At Once
I'm trying to use the Build variables in a script. According to this documentation I should be able to use the following:
Write-Host "BUILD_DATE: $Env:BUILD_DATE"
Write-Host "BUILD_REV: $Env:BUILD_REV"
However, I only get the following output
BUILD_DATE:
BUILD_REV:
I've also tried this syntax:
Write-Host "BUILD_DATE: $(Env:BUILD_DATE)"
Write-Host "BUILD_REV: $(Env:BUILD_REV)"
Write-Host "BUILD_DATE: $(Build.Date)"
Write-Host "BUILD_REV: $(Build.Rev)"
But the first segment gives The term 'Env:BUILD_DATE' is not recognized and the second segment gives The term 'Build.Date' is not recognized
How can I use the build variables in my script?
Disclaimer: I know virtually nothing about Azure pipelines, so my answer is based on reading the docs. Do let us know if I got things wrong.
Your first command uses the correct syntax for referencing environment variables in PowerShell (also inside an expandable (double-quoted) string).
(The other commands, based on subexpression operator $(...), mistakenly try to execute commands named Env:BUILD_DAT, ... rather than referencing variables.)
Your problem seems to be that the targeted environment variables do not exist.
The list of predefined variables that are exposed as environment variables does not contain variables named Build.Date / $env:BUILD_DATE and Build.Rev / $env:BUILD_REV.
By contrast, variables named Date and Rev seemingly do exist - as you state, they are used in the default format definition for the Build.BuildNumber / $Env:BUILD_BUILDNUMBER build variable, $(Date:yyyyMMdd)$(Rev:.r) - but are seemingly of a different kind not exposed as env. vars. (unlike Build.BuildNumber / $Env:BUILD_BUILDNUMBER itself, which is exposed).
(I don't know where these variables are defined or how they are classified, and where this is documented - do tell us if you know.)
A quick workaround would be to split the value of $Env:BUILD_BUILDNUMBER into its constituent parts:
# Split the build number into date and revision, by "."
$date, $rev = $Env:BUILD_BUILDNUMBER -split '\.'
"BUILD_DATE: $date"
"BUILD_REV: $rev"
From my linux days I remember that !$ was a really useful shortcut to get the last argument from the previous command on the tcsh command prompt.
Does PowerShell has anything like this?
(it must be short, not anything like [System.Linq.Enumerable]::Last(((Get-History -Count 1).CommandLine -split ' ')))
You should be able to use the $$ automatic variable. There is also $^ that means "first token in last line received by the session."
I recommend reading the about_Automatic_Variables help topic for more information.
I have the following file:
firstname,lastname,email
jane,doe,jane#example.com
drew,neil,drew#vimcasts.org
john,smith,john#example.com
I execute 1,$!sort -property #{"Expression"={$_.split(',')[1]}}
It outputs the following error:
At line:1 char:49
+ sort -property #{Expression={$_.split(',')[1]}} <C:/Users/wild/AppData/Local/Tem ...
+ ~
The '<' operator is reserved for future use.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : RedirectionNotSupported
In my _vmrc:
set shell=powershell\ -ExecutionPolicy\ Unrestricted\ -NoProfile\ -NoLogo\ -NonInteractive
set shellcmdflag=-command
set shellpipe=|
set shellredir=>
Also I've tried with no result from here:
if has("win32")
set shell=cmd.exe
if has("gui_running")
set shellcmdflag=/c\ chcp\ 65001\ &&\ powershell.exe\ -NoLogo\ -NoProfile\ -NonInteractive\ -ExecutionPolicy\ RemoteSigned
else
set shellcmdflag=/c\ powershell.exe\ -NoLogo\ -NoProfile\ -NonInteractive\ -ExecutionPolicy\ RemoteSigned
endif
set shellpipe=|
set shellredir=>
endif
How to use Sort-Object cmdlet with vim?
I ran into the same issue. In theory, you should be able to use pipes instead of the input redirection operator '<' by setting noshelltemp in Vim, but it's not currently implemented in Windows:
'shelltemp' 'stmp' boolean (Vi default off, Vim default on)
global
{not in Vi}
When on, use temp files for shell commands. When off
use a pipe. When using a pipe is not possible temp files are used
anyway. Currently a pipe is only supported on Unix.
So, it looks like we are stuck for now...
Purely from PS user perspective: the issue with this approach is the fact, that PowerShell (as error message tried to explain) does not have < operator. It's one of few reserved but not yet implemented (probably due to relatively low demand).
Unless there is a way to force vim to use "usual" PowerShell syntax with piping elements into Sort-Object, you won't get far.
I'm trying to set up a PowerShell profile so all of my machines have a common profile. I'm making each machine's profile run a script in my dropbox so I can update all of them easier.
I thought the problem was I didn't know dot-source syntax well, but it turns out PowerShell really doesn't like that the path to my documents folder has an apostrophe. The full path is:
d:\Owen's Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
If I delete that file, PowerShell starts up fine (of course, without the modifications I want.) If I create that file, I get an error when PowerShell starts up:
The string starting:
At line:1 char:75
+ . 'D:\Owen`'s Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 <<<< '
is missing the terminator: '.
At line:1 char:76
+ . 'D:\Owen`'s Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1' <<<<
+ CategoryInfo : ParserError: (:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : TerminatorExpectedAtEndOfString
It can't be my fault, because the script itself is empty. Deleting the empty file makes it go away, creating the new file makes the error come back. Surely Microsoft anticipated profile paths with apostrophes?
Update
Crud. Looks like an old issue. Maybe there's not a workaround. :(
Update 2
I had a conversation with #Lee_Holmes on Twitter about this. Apparently it's been fixed in some super-awesome internal Microsoft version, but there's no hotfix available and no time table for fixes since PSH is now a Windows Component. That makes Roman Kuzmin's answer below the most appropriate answer (use one of the global profiles), or perhaps "rename your My Documents folder" which hasn't been mentioned yet.
The similar bug is reported and presumably acknowledged:
Powershell errors with apostrophe in path
The error message is different though, due to a different PowerShell version, more likely.
Perhaps there is no direct workaround: this faulty call is not under our control. If renaming of the troublesome directory is not an option then perhaps an alternative location of the profile can be a suitable solution. Try to put your profile to $PsHome.
> man about_profiles
...
For example, the Windows PowerShell console supports the following basic
profile files. The profiles are listed in precedence order. The first
profile has the highest precedence.
Description Path
----------- ----
Current User, Current Host $Home\[My ]Documents\WindowsPowerShell\Profile.ps1
Current User, All Hosts $Home\[My ]Documents\Profile.ps1
All Users, Current Host $PsHome\Microsoft.PowerShell_profile.ps1
All Users, All Hosts $PsHome\Profile.ps1
...
The last two profile locations should work for you (unless $PsHome contains problem characters, indeed).
Try using the following escape sequence:
d:\Owen`'s Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
I just ran into this issue myself. I am running PSv5. I tried to get around it using the grave accent as well but I found that didn't work for me. So I thought "let's see what intellisense does with it" and sure enough it found the solution:
Use two apostrophes!
PS> $path = 'd:\Owen''s Documents'
PS> $path
d:\Owen's Documents