PowerShell with a configuration script - powershell

Needs some help. We run PowerShell scripts using a configuration script.
e.g. .\folderA\TheConfigurationScript .\scriptThatDoesAllTheWork.ps1
The issue is that in the directory where scriptThatDoesAllTheWork.ps1 is located there are number of other scripts.
If I accidentally add a space before scriptThatDoesAllTheWork.ps1 all scripts located in that folder are executed
e.g. .\folderA\TheConfigurationScript
.\ scriptThatDoesAllTheWork.ps1
All variables therefore defined in folderA\TheConfigurationScript are available to scriptThatDoesAllTheWork.ps1 that does all the work
Is there any way to avoid this behaviour
Thanks in advance

Thanks to mclayton. I had a get-childitem that would return all the files in case of space. In case this helps anyone

Related

Creating files at PSModulePath in batch

I am currently trying to write a batch program that installs a module named SetConsolePath.psm1 at the correct location. I am a beginner with Batch and I have absolutely no powershell experience.
Through the internet, I have learned how to display PSModulePath with powershell -command "echo $env:PSModulePath.
How can I, via .bat file, move SetConsolePath.psm1 from the desktop to the location displayed by powershell -command "echo $env:PSModulePath?
Thank you in advance, and I apologize for my lack of experience.
Before I answer, I must out that you do not want to copy PowerShell module files directly to the path pointed by PsModulePath. You really want to create a folder inside PSModulePath and copy the files there instead.
The prefix env in a Powershell variable indicates an environment variable. $env:PSModulePath is actually referring to the PSMODULEPATH environment variable. On the command line, and in batch files, environment variables can be displayed by placing the name between percent symbols. (In fact, you could have displayed this value by typing echo %PSMODULEPATH% instead.)
To reference the desktop folder, have a look at this answer, which shows you how to use another environment variable, USERPROFILE.
Therefore, to copy the file from the desktop directory to the path specified in PSModulePath, you would do this:
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%"
And, as I warned earlier, you really should copy the file to a folder underneath PsModulePath. So what you really want is:
IF NOT EXIST "%PSMODULEPATH%\MyNewFolder" MKDIR "%PSMODULEPATH%\MyNewFolder"
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%\MyNewFolder"

Properly referencing scripts in PowerShell

I'm a newbie in PowerShell and I'm having some problems when defining some utility scripts that are "included" in other files; the problem is regarding paths. Let me explain the issue with a simple example:
Imagine you have some utility script named utility.ps1 located under /tools and you want to invoke it from a build.ps1 placed under /build. Now imagine that the utility.ps1 invokes some other utility script in the same folder called "utility2.ps1". So,
utility.ps1:
[...]
.".\utility2.ps1"
[...]
build.ps1:
[...]
."..\tools\utility.ps1"
[...]
The problem here is that when calling from build to utility.ps1 and then from this last one to utility2.ps1, powershell is trying to load utility2.ps1 from the current dir (build) instead of the tools dir.
My current workaround is pushd . before calling and popd after that but it smells bad, I know; on the other hand if some day I move scripts to some other location I'd need to update all my scripts that use the moved one... a mess.
So, I'm doing something very wrong; what would be the proper one to do this, making the client script unaware and independant of the "utility" script location?
The answer by PetSerAl in the comments is perfect but will work for PowerShell 3+. If for some reason you want your script to be backward compatible as well, then use the below code snippet to find the $ScriptRootPath (which is automatically populated via $PSScriptRoot for PS 3+)
$ScriptRootPath = Split-Path $MyInvocation.MyCommand.Path -Parent
For PS 3+, populate this variable via the global variable:
$ScriptRootPath = $PSScriptRoot
and then use the solution as described by PetSerAl,
i.e. for utility.ps1: . "$ScriptRootPath\utility2.ps1"
for build.ps1: . "$ScriptRootPath\..\tools\utility.ps1"
Also refer this question on SO

Powershell: Copy-Item -Recurse -Force is not copying all sub files

I have a one liner that is baked into a larger script for some high level forensics. It is just a simple copy-item command and writes the dest folder and its contents back to my server. The code works great, BUT even with the switches:
-Recurse -Force
It is not returning the file with an extension of .dat. As you can guess what I am trying to achieve, I need the .dat file for analysis. I am running this from a privileged account. My only thought was that it is a read/write conflict and the host file was currently utilizing it (or other sys file). What switch am I missing? The "mode" for the file that will not copy over is -a---. Not hidden, just not copying. Suggestions elsewhere have said to use xCopy/robocopy- if possible I do not want to call another dependancy- im already using powershell for the majority of the script, id prefer to stick with it....Any thoughts? Thanks in advance, this one has been tickling my brain for a little...
The only way to copy a file in use is to find the locking handle close it then retry the copy operation(handle.exe).
From your question it looks like you are trying to remotely copy user profiles which includes ntuser.dat and other files that would be needed to keep the profile working properly. Even if you did manage to find a way to unload the dat file(s), you would have to consider the impact that would have on the remote system.
Shadow copy is typically used by backup programs to copy files in use so your best bet would be to find the latest backup of each remote computer and then try to extract the needed files from the backed-up copies or maybe wait for the users to logoff and then try.

Current working directory for SXPG_COMMAND_EXECUTE?

Is there a way to specify the current working directory for the system command executed by the function module SXPG_COMMAND_EXECUTE?
I do not see any parameter which would allow me to do that either by defining the command in transaction SM69 or on the list of IMPORTING parameters in SE37.
It looks like by default such commands are started in DIR_HOME which can be viewed by the transaction AL11. Do I have any control over that?
There isn't a way of doing it via `SM69' unfortunately. I think the only solution is to create a script and call that.
I was going to suggest wrapping the statements in a SM69 command defined as a call to sh with parameters of -c 'cd <dir> && /path/to/command' but unfortunately that doesn't work. According to note 401095 wildcards are not permitted. When I tested, && was translated into a single &, causing the command to fail.
Would be good if you access this information using FM FILE_GET_NAME_USING_PATH (export the script name for which you want to find the physical directory).
The recieving path can be used in SXPG_COMMAND_EXECUTE.
Because the external commands I called were actually .bat files I solved this by putting the following expression at the beginning of each and every one.
cd /d %~dp0
This Stackoverflow question helped a lot actually.

MS-DOS commands doesn't work (COPY and ERASE)

I have done this .bat file to copy some maps and textures from my USB drive to the valve installation path, but it doesn't work, why?
#echo on
COPY \CS-Fix\Maps\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\maps
COPY \CS-Fix\Textures\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\
ERASE %PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp
pause
What is wrong?
The %PROGRAMFILES% indicates that you're using Windows, not MS-DOS.
MS-DOS was Microsoft's variant of DOS, an operating system that preceded Windows.
Anyway, two main problems are apparent to my tired eyes:
Paths that possibly have spaces and are not quoted.
Probably no write access to the relevant folders.
To fix the first problem, quote paths.
The second problem is only a problem in Windows Vista and later.
You can probably fix that by running the batch file from an elevated command prompt.
I assume that the batch file is sitting on and being run from your thumb drive.
Do the paths need to be quoted?
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause
You might need to quote things. %PROGRAMFILES% probably expands out to C:\Program Files. Try something like this:
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause