I have a PowerShell utility that historically is run from a shortcut, and stored on a network share, so the path in the shortcut for the -file argument is a full UNC path. I am implementing a Work From Home version, where I zip up the network folder along with a shortcut with relative path to one of the utilities. That all gets unzipped on the user desktop of the home machine, the I do a Copy-Item -recurse to C:\Program Files. I expected I would then need to revise the path in the -file argument for all the included shortcuts. But to my amazement those paths are automatically getting revised. This does not happen if I copy to any other location, which has me thinking it is a special behavior associated with copying a link into Program Files. It happens when I copy the folder manually too.
I am VERY happy with Microsoft making something easier for once, but I can't find any documentation on this behavior, and I worry that
1: this might not apply to every build of Windows 10, or
2: It might actually be a side effect, not a feature, and be broken in some future update
Does anyone know of some documentation related to this? Something that would assure me that taking advantage of this isn't going to break in future?
Related
I am trying to use models from Hugging Face, but VS code always downloads them into my very limited C: drive; C:\Users\<user>\.cache.
How can I force it to cache to a different drive?
Things I've tried:
Googling: only seen threads for Linux, whose commands do not transfer over. Could not find clear equivalent commands for Windows.
Running a new instance from terminal code --user-data-dir E:/.cache
Fully un-installing VS Code, downloading a portable version, and making a data folder (following these instructions)
All of them still result in caching to C:\Users\<user>\.cache.
From some further research, it appears this is currently not possible.
However, I've found that symlinks is a great temporary workaround. In short,
Create a folder on a drive/partition with an abundance of space, i.e. E:\TempCache
Close any instances of VS Code, if any.
Navigate to C:\Users\<username>\.cache. If there's anything in it, cut them over to E:\TempCache, and delete the whole .cache folder.
Open cmd with admin rights, and enter mklink /J "C:\Users\<name>\.cache" "E:\TempCache". This will re-create an empty .cache folder.
Next time VS Code is ran, it will automatically detect and use the .cache folder on the C drive like nothing changed.
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'm using VS 2015, so the TFSCMDLets add-in for 2015. TFS server is 2013.
The old "New-TfsPendingChange -Rename" syntax that I found here on SO is no longer supported, both per the docs and per the error messages I get when I try.
I can't just check them out and rename them using the filesystem rename command, because that causes TFS to lose track of the file.
I've also tried this using tf.exe, where the commands I need are available, but it can't seem to figure out the workspace to use, even though the containing folder only maps to a single workspace. In this case it works fine when passed a literal filename, but fails when passing a path using foreach, like this:
tf workspaces /collection:devtfs\DeltaWA_ITA_BI
dir "C:\TFS\BusinessIntelligence\Database\Reporting_Prod\Test Views\" -filter "*.View.sql" | foreach { $newname = $.Name -replace ".View.sql", ".sql"; tf rename $ $newname }
Does anyone have a sample script that works in VS2015, TFS 2013?
You should avoid renaming items managed by TFVC using your operating system (for example, using Windows File Explorer, or the rename command in the Windows command prompt). Instead, do this in Source Control Explorer:
In Source Control Explorer, select the file that you want to edit,
open its shortcut menu, and choose Rename.
Type the desired name for the item.
If you want to use command prompt or script to do this, you could use tf rename command. Not sure the detail error message for your workspace error.
However, you need to make sure that you are running the commands from a mapped folder, you can run tf workfold to double check if the current folder is mapped or not.
If it's mapped and the error still exists, you might have a problem with your workspace cache. Try to remove cache through tf workspaces command:
tf workspaces /remove:(*|workspace1[,workspace2,...])
/collection:(*|TeamProjectCollectionUrl)
The overall answer turned out be in two parts:
1. You really must execute tf.exe in the folder where you want the work done. I saw this in the code I looked at, but didn't understand it was a requirement.
2. This means you have to get tf.exe into your path. Got help from a coworker on that.
After that, my tiny script worked as desired.
I still don't see a way to do this with TFS CMDLets. This is kind of a pity, bu not really important.
Thanks for the assistance!
Everytime i dot source a file in PowerShell it opens a copy of the file in notepad.
Exe:
.\MyScript.ps1
The script runs fine - its just really annoying having these pop up all the time. Is there a way to suppress this?
I'm on windows 7 x64 and using the latest version of PowerShell.
Ex2: This is still launching notepad.
cls
Set-Location "\\PSCWEBP00129\uploadedFiles\psDashboard\"
. .\assets\DCMPull\Powershell\SqlServerTransfer.psm1
. .\assets\DCMPull\Powershell\RunLogging.psm1
You cannot dot source PowerShell files with the .psm1 file extension. One option is to rename them to .ps1.
Alternatively (and, in my opinion the better approach), you can load the PowerShell modules using Import-Module <module.psm1>. Just note that the behavior of Import-Module is different from dot sourcing it. Dot sourcing runs the script in the current scope and also persists all variables, functions, etc.in the current scope. Import-Module does not do that.
Although not very common, you can also export variables from modules with Export-ModuleMember.
Adding to Raziel's answer, there's a lot of thought that went into only being able to dot source files with .ps1 extension, and otherwise why it tries to run it as a system executable. Here's a snippet from PeterWhittaker on GitHub:
. ./afile would only execute something if there's either an
extension-less but executable aFile in the current dir, or a
(not-required-to-be-executable) afile.ps1 file, with the former taking
precedence if both are present; if the file exists, but is neither
executable nor has extension .ps1, it is opened as if it were a
document.
. <filename> with <filename> being a mere name (no path component) by
(security-minded) design only ever looks for a file of that name in
the directories listed in $env:PATH (see below), not in the current
directory.
I encountered exactly the same situation : If the point source imports the .psm1 file, the file will be opened directly instead of importing the code in the file.
Because the function of point source import is only valid in the file with suffix of.ps1, if the suffix does not meet the requirements, it will not be regarded as path, but as a code , so it is like running the corresponding string directly, and the effect is naturally to open the file.
So,this phenomenon is not aimed at .PSM1,if you change the extension to TXT, it will have the same effect. It will have the same effect for any file whose suffix is not .PS1.
You can bypass this problem by creating symbolic links or hard links!
In PowerShell 7, it's easy to create links using New-Item.
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.