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
Related
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.
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 have read this answer stackoverflow answer and it get's me there half way. Here is what I need to do.
Execute this command:
"c:\myexe.exe <c:\Users\Me\myanswerfile.txt"
If I run that straight from within my powershell script
&'c:\myexe.exe <c:\Users\Me\myanswerfile.txt'
I get this error:
The term 'C:\myexe.exe <c:\Users\Me\myanswerfile.txt' is not recognized as the name of
a cmdlet, function, script file, or operable program. Check the spelling of the name,or
if a path was included, verif that the path is correct and try again.
Now I have tried several variations of this including placing the original command in a variable called $cmd and then passing the
If I append the '<' to the $cmd variable the command fails with a similar error as the first one.
I'm stumped. Any suggestions?
If you want to run a program, just type its name and parameters:
notepad.exe C:\devmy\hi.txt
If you want to run an exe and redirect stdin to it which your example seems to be an attempt of, use:
Get-Content c:devmy\hi.txt | yourexe.exe
If you need to specify the full path to the program then you need to use ampersand and quotes otherwise powershell thinks you are defining a plain string:
&"C:\Program Files (x86)\Notepad++\notepad++.exe"
Simply use & operator
& "Program\path\program.exe" "arg1" "arg2" ....
I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.
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