Powershell dot sourcing opens up file in notepad - powershell

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.

Related

Copy PowerShell shortcut to Program Files, repath -file argument magic

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?

Change Directory to Folder Containing PowerShell Script - Regardless of Where That Folder Is Located

I have a script that I've created to prep our customer's servers for a software install. Part of this requires the script to be run as administrator, so just instructing people to click "Run With Powershell" doesn't get the job done. The script is in a folder with a number of .ini files that the script needs to copy to different server locations. If I just right-click the Powershell script and select "Run With Powershell," it is able to find the files and copy them without issue. Unfortunately, if I open the script in ISE, it opens with a default directory of C:\users\user, and I can't seem to copy those .ini files without first running a change directory command to get us to the folder that the script and the .ini files are in. But I'd like our installation techs to be able to run this without worrying about the exact location they initially drop these folders. I'd also like them to not have to worry about changing the directory manually in PowerShell. Some of our customers have multiple drives, and it might make sense to put this stuff on something other than the C drive, so it's hard to tell where this folder might end up. But I'm not sure of a command that will get me to the directory of the *.ps1 file, without knowing where that file is beforehand... Anyone have a suggestion?
You can use $PSScriptRoot that will have the location of the directory where the script is located.
This is referenced in the following post:
How can I get the file system location of a PowerShell script?

Is it possible to run a batch file from package manager console?

I'm using code first migrations with my context class in a class library (ie not the startup project) and I want to make batch files for the common operations to save having to pass in the parameters each time I want to add-migration and update-database. I ran the "dir" command in the console and it appears to be in the solution root folder so I have tried creating a .bat,.cmd or .ps1 file in the Solution Items folder but the package manager powershell doesn't seem to be able to find it?
At this very moment I am happening to read this from Bruce Payette's "Powershell in Action" (Wonderful book) so share something with you, lucky guy:
"In this example (Poster: an example in the book), even though hello.ps1 is in the current directory, you had to put ./ in front of it to run it. This is because Powershell doesn't execute commands out of the current directory by default. This prevents accidental execution of the wrong command."
Looks like I needed to just put a ".\" on the beginning of the batch file name - not sure if Powershell requires this to execute?

xcopy is not recognized as an internal or external command, operable program or batch file

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.

PowerShell module changes not visible

I'm confused as to how PowerShell modules work.
I have downloaded and copied a module from a blogger. I've unblocked and extracted the .zip to %USERPROFILE%\Documents\WindowsPowerShell\Modules\SomeModule
In this folder is a .NET assembly that the module uses, but doesn't not contain compiled CmdLets. Instead, the commands are functions in a .psm1 file and a .psd1 file describes the manifest.
If I open PowerShell, the functions are available and work but I want to add my own function, so I have added it, however I cannot see it. I've restarted all PowerShell instances, removed the module and imported it again.
As a test, I renamed an existing, working function. Interestingly, after remove and import the function disappears instead of adopting its new name. If I rename it back (just a single character change) and remove/import then it appears again.
I use help blahblah to list all commands in a set, since they all have the same prefix. The manifest exports all (*) functions. Clearly I don't understand how these type of script modules work, the functions are all listed even after I run Remove-Module! I've written a compiled module before in C# and that worked as expected.
What's going on? Why does renaming a function cause it to vanish? Thanks.
Found it. This line appears in some stuff I overlooked in the .psm1 file.
Export-ModuleMember X, Y, Z
So, I guess the manifest can overrule this or replace the need for it in a script? Who knows. Anyway, hope this helps someone.