I have just installed the new Powershell 7.2 release from the Windows store on my Windows 10 computer.
When I run the application, the default starting path is C:\Windows\System32.
How can I change this default to to a C:\Users\<username> path, since I would like to avoid having to cd or Set-Location every time I use Powershell.
I looked at some other questions related to this topic, but wasn't sure if it still applies to the new release and didn't want to change anything that might mess up my settings and cause problems.
Steps validated in Powershell 5.1 environment:
Check your profile file location. Mine is:
PS C:\Users\alex> $PROFILE
C:\Users\alex\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Modify your profile Microsoft.PowerShell_profile.ps1
Change starting location to the directory you want:
Set-Location C:\Windows\alex
Start new Powershell window
Hope this works for you.
Related
While learning Anaconda I had a problem with "cd" not working in Anaconda PowerShell, so I did what is recommended here, manually created a profile and set the path to a specific folder. It worked.
But today somehow I found "cd" is working for me again, so I was going to delete that ps1 file. But the folder together with the file in that was no loner there, completely gone. Now I am stuck with my temporary path on every PowerShell start-up.
According to Microsoft documentation, $profile should return my profile variables, which it did:
C:\Users\myname\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
But first, this is not the file name I gave it; second, this path is also non-existent, both folder and file.
I tried notepad $profile, then Notepad told me "The system cannot find the path specified." But it is exactly the path the system told me.
Some answer I saw here says that is because my profile is non-existent, I need to create one first. That is not the case here. I definitely overwrote my starting path, but I cannot find the actual profile file to edit that back.
I also tried doing it the same way again but changing "YOUR_FILE_PATH" into "%Home" hoping to "overwrite" it back, yet somehow this time it did not work and the file did not disappear as it did the first time.
I am really confused on this.
If you want to reset PowerShell to the original settings when PowerShell was installed.
Uninstall PowerShell from the Add or Remove Programs.
Restart your computer.
Reinstall PowerShell.
I have flutter installed and everything works fairly alight but every time I run a flutter command I get the following message before the command actually runs.
Error: PowerShell executable not found.
Either pwsh.exe or PowerShell.exe must be in your PATH.
I added the Powershell.exe path to my PATH variable (both System & User) and also added C:\Windows\System32 as I read that on one of the Github/SO forums. Any idea how to get rid of this? I am following a Udemy course and have followed every instruction to the dot but the instructor does not get this message.
Go "Edit environment variables for your account" under "User variables" add to Path this line
C:\Windows\System32\WindowsPowerShell\v1.0
It solved my problem.
Add this to user Path variables and system path variables
C:\src\flutter\bin
Add these to Environment System Path Variables
C:\Program Files\Git\cmd
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32
My problem was the missing of 3rd from System path variables.
I have lost half a day to solve it and used all instructions on flutter site and and answers about powershell path. It didnt work until add C:\Windows\System32 to Path variable.
copy the path, for my case, it is "C:\Windows\System32\WindowsPowerShell\v1.0" and pastes it in environment variables as a path
In case you encountered this problem and none of the above solutions worked for you. In my case, I set all the environment variables - I am using Windows 10. I even reinstalled flutter; but the problems persisted.
It turns out my Anti Virus had quarantined the Powershell executable file. I had to open the anti virus quarantine chest, restored the Powershell executable and restarted my VS Code.
Problems solved, after three days of searching for solutions.
One can specify the extension dir by running from command line:
code --extensions-dir c:\path\to\ext
However, I would like to set this parameter even when running from the windows menu.
I tried to modify the argv.json file located in the .vscode folder (like for https://code.visualstudio.com/docs/getstarted/locales).
It didn't work.
Does anybody know how to fix this?
Bests
Try creating an environment variable called VSCODE_EXTENSIONS with the value of c:\path\to\ext
As a complement to DG's response
If the VSCODE_EXTENSIONS environment variable is created as a system variable, it seems to affect all users.
In my case, I performed the following steps:
close VSCode on all users (I usually have one session open as
administrator and another as non-administrator)
set the variable VSCODE_EXTENSIONS = c:\ProgramData\Code\extensions\
moved all extensions from the extensions folder of the administrator to c:\ProgramData\Code\extensions\
restart the computer
log in with both users and the extensions were available
It is convenient to mention since then the extensions installed by administrator are available to all users and are installed in the folder mentioned previously.
I have a script in Powershell ISE that I've added to my ISE profile (The only profile I have) through dot-sourcing. Whenever I open ISE, the version of the script that's loaded is 3.7.2. However, the current version of the script (which the path for the dot-sourcing points to) is 5.3. If I copy the dot source line in my profile and paste it and run it in ISE, the script will then correctly show as 5.3. I've even removed the line from my profile, and the command still shows up when ISE is loaded.
Now, it seems like the script is being cached somewhere. I've checked in my WindowsPowerShell\Modules folder, but I only have modules for ImportExcel and WASP. I never made it into a module in the first place, and I don't see it listed anywhere in Get-Module. Currently the line referencing adding my script is removed from my profile, and checking $profile.Contains("Create-Cert") returns False, which to me means that it's loading the correct file. Another thing I tried was to Dot-Source my $profile in ISE, which did seem to run successfully, but still didn't have the current version, whether or not the dot-sourcing inside $profile was there.
Is there somewhere else that Powershell could be storing this old version of this script? I've searched my computer for references to it, but I can't even find an old version that matches 3.7.2.
Edit: Another troubleshooting step that I've just attempted was to rename my profile and then open ISE. When I did this, the command no longer showed in my command list, and Get-Help Create-Cert came back with an error since it couldn't find it. I then changed the name of my profile back to Microsoft.PowerShellISE_profile.ps1, closed and opened ISE again, and the command loaded with version 3.7.2 again. It's almost like the command is embedded into the profile itself, which I don't even think should be possible.
One additional thing I want to note is that this script exists on a server, and not locally on the computer. I don't think that should matter, since the server is accessable the entire time, but perhaps there's something caching due to that fact.
Edit 2:
On recommendation of Tom Collins, I created a new profile and added just the line concerning my script to it, and this time it worked. When ISE loaded, it correctly loaded version 5.3. I then swapped the naming of my old and new profile, and suddenly it loaded the correct version again. I've tested closing and opening it a few times, and now it's loading 5.3 each time. I'm still at a complete loss for what actually fixed it, and if anyone is willing to offer a deeper explanation I'd be willing to know more.
Adding my triage in as an answer.
Next step I'd take is to rename the original profile, load ISE to confirm it isn't loading, and then manually rebuild a new ISE profile file with just the script (and minimal pre-reqs). Save that as the new profile file and re-run. If that works, then there's something in your original profile that is loading the old script.
I have a problem using 'xcopy' command.
I'm building a C# project with msbuild. At the end of the build, a batch file is called to copy my assemblies from Debug/Release to some other folders.
Here is the problem, my build fail and the error log is 'xcopy is not recognized as an internal or external command, operable program or batch file'.
The path is correctly set, xcopy do works from a windows command line and from the visual studio command line (the one set with the project environment).
I tried to set the path in the batch file but it doesn't help.
Any suggestion?
I'm using windows 7
Cheers :)
I encountered the same problem.
It seems to be a problem with the path environment variable within Visual Studio.
When I added a "path" statement to the beginning of my build event, it produced the following output:
PATH=
This seems to indicate that the path is empty within the VS build environment.
When I specify the full path to xcopy like this, the problem went away:
%systemroot%\System32\xcopy ...
I'm not sure what caused Visual Studio to lose it's path.
Set Environment variable PATH = %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
This is not a problem with Windows 7 or 8. It's actually a problem with applications that update environment variables such as PATH.
The PATH is stored in the Registry as an "Expandable string value" (REG_EXPAND_SZ), but a lot of applications write it back to the Registry as a "String Value" (REG_SZ). If your path contains anything like %SYSTEMROOT%, this will not be expanded into C:\Windows (or whatever yours is) if the path is stored in a REG_SZ.
The fix is simply to edit your path manually from the control panel. You need to make a change (eg add a ; to the end of the path) and then apply it. This will fix up your path in the Registry to be a REG_EXPAND_SZ.
(Go to the System Control Panel and select Advanced System Settings. Edit the Path Environment variable in the lower box, and that should fix it.
You can tell whether your path is broken in this way by opening a command prompt and typing PATH. Your path will be listed. If you can see anything enclosed in % % then your path is not being expanded.
It happened to me after I updated one of my Visual Studio extensions, during which Visual Studio was closed and reopened by the updater. I could no longer properly build my project. I closed Visual Studio and reopened it and the problem went away.
I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.
Eileen
I also had a problem with xcopy (same error message) - with a very simple batch program that I use to backup files to a removable drive. Have been using that program for at least 5 years with never a problem. Then yesterday xcopy is unknown to Win7. The replacement of xcopy with %systemroot%\System32\xcopy at each instance solved the problem. Very strange.
Go to environment variable and correct PATh including ; in last.
It will work, this is not at all related to OS or Technology.
It's working for me, Not even need to restart OS, Just open new command prompt.
[Fixed for me]
After adding the correct paths to "Path" environmental variable it still doesn't work (for cmd and VisualStudio) (even after restarting the PC).
The problem was in broken register parameter:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
ParameterName=PATHEXT
I had the value .wlua;.|exe. Maybe was broken after installing something.
Everything works again after changing it to:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Hope this helps if nothing other works.