For normal use, I want my script to output a lot of Write-Host to highlight information with colour (I am aware of how -Host commands can create some confusion beside pipeline commands as -Host commands just push to the console, but I am ok with that). In my script, there are a few hundred Write-Host statements and I have simple logic to make the script attended or unattended using some choice options along the way, but I realised that at a certain point I might want to make it completely silent, ideally without having to delete all of the Write-Host statements.
So, might there be a way to put in some kind of directive to a script to make it globally ignore all Write-Host commands (or for selected regions) and then my script can run completely silently when I want it to?
Related
I am working on a project with around 40 script files and I am going to package the scripts to distribute them to my clients (kind of like a version release). I don't want my clients to change my scripts (at least make it hard for them to change).
I have made certain files Read Only by setting the execution policy but the clients can simply set it back to writable so I want to add in a few lines of code (preferably less than 5) to check that the scripts are not modified.
I am aware of using property LastWriteTime will do it but I will need to do this for each of the script (a hash table to keep track of the LastWriteTime for each file will be to long and not clean enough) which is not ideal.
I have also considered Get-FileHash but I am concerned about the hash code will change each time I run it.
As you already have realized, it is impossible to prevent clients from modifying scripts in water-tight a way. Bruce Schneier sums it up nicely: "Trying to make bits uncopyable is like trying to make water not wet."
To run a script, one needs to copy it at least in system's memory - and at that point you've lost control. What's to prevent copying the script in alternate a location and editing it before running? Nothing, unless you have tight control on client. Should you have tight control, setting execution policy to signed prevents running unsigned scripts. Until the client starts Powershell from command line with -Executionpolicy Bypass switch. The execution policy isn't a security system that restricts user actions .
There are a few approaches that can hinder editing, but a determined hacker can overcome those. So the root question is: why? Why shouldn't the clients modify the scripts? Is it to protect some IP? Are they trying to achieve something the scripts are not designed to? Something else?
A simple solution is to use a tool like PS2EXE that converts Powershell script as an executable. The contents can be extracted and modified, but it requires at least a bit more effort than running Notepad.
Another approach would be modules. Distribute the scripts as a Powershell module that the clients will import. Editing a module requires a bit more effort than editing a simple script file, but is quite possible too.
I have the code below which executes an exe file and then i want the path which is assigned to a variable to be copied into the text box of that exe and once it gets copied then the next button in the exe should get clicked\executed automatically by powershell.
& "D:\SOFTWARE\notepad ++.exe"
$Path="C:\Program Files"
Basically i will be using this code for some other exe file but process would be same. So is there any way by which i can do this by using powershell?
Consider the snapshot below of the UI of application installed. If i want to pass the product key which i have declared in a variable inside the powershell after passing it to the application and then i want its Get Product Details button to be hit\Run.
What you actually want is pass the variables into the msi by running it quietly without UI. Try the following first (assuming your exe is actually just an MSI wrapper)
msiexec.exe /i $PathToExe /q /l*vx log.txt
This should quietly launch the msi and produce a log.txt file. Wait a few moments for it to complete since it is installing in the background. Then check if it correctly installed. Then check the log file to see all the variables that were set at the end. Guessing by their names or values, you could then pass them in the next time simply by adding variablename=variablevalue to the command line call. You might need to experiment and learn a bit about MSI and msiexec as part of this.
If talk about invoking UI actions in general, then you would need to look at the AutomationElement class but it can get very complex here on...
You should look at using SendKeys.
https://blogs.technet.microsoft.com/heyscriptingguy/2011/01/10/provide-input-to-applications-with-powershell/
So I'm using PowerShell to manipulate a SharePoint 2010 library. I am uploading, downloading, and deleting files in a script using a custom module I made. My errors are so odd I can't understand them.I am using PowerGUI, Windows PowerShell ISE, and PowerShell Management Shell all in admin mode.
PowerGUI:
I sometimes can't get an spWeb object, sometimes I can. The URL string is being pulled from a CSV file so it never changes and neither does the code before I call Get-SPWeb -Identity $correctURL
Sometimes when I call a list RootFolder it returns $false for the Exists property, using management shell I can get past this. Otherwise I can touch it by calling $ListName.RootFolder.Files and it will magically return and hold the $true for Exists in future executions of my script.
Then when I call an XML file full of file properties(for uploaded files) it will return file property names for $fileFieldsXML.row.Attributes | foreach {$_} and values for $fileFieldsXML.row.Attributes | foreach {$_.ToString()}. This is, unless I set them to variables. When two very distinct vars are set to these two differentish calls they both are set to the array of property names! Why??
Windows PowerShell ISE and PowerShell Management Shell
I think these are just outdated somehow. I can call Get-SPWeb in Management Shell but I can't in ISE due to I guess outdated versions. Lately the management shell will act as if I haven't been doing anything to the files unless I close it out and reopen it. Does the management shell just hold a copy of all files when it starts or something? Can I make it update these files?
Can anyone suggest a better way to debug? Also why does a module seem to severely increase runtime? When everything was in the same script it was quick but my long functions take several times longer to execute now.
I also have been using PowerShell and SharePoint for almost two months now, so I am a beginner and intern. Perhaps that is really the cause of my problems :)
What is the best and correct way to run a PowerShell script from another one?
I have a script a.ps1 from which I want to call b.ps1 which does different task.
Let me know your suggestions. Is dot sourcing is the best option here?
Dot sourcing will run the second script as if it is part of the caller—all script scope changes will affect the caller. If this is what you want then dot-source,
However it is more usual to call the other script as if it were a function (a script can use param and function level attributes just like a function). In many ways a script is a PowerShell function, with the name of the file replacing the naming of the function.
Dot sourcing makes it easier to at a later stage convert your script(s) into a module, you won't have to change the script(s) into functions.
Another advantage of dot sourcing is that you can add the function to your shell by adding the file that holds the functions to Microsoft.PowerShell_profile.ps1, meaning you have them available at all times (eliminating the need to worry about paths etc).
I have a short write-host at the top of my dot sourced files with the name of the function and common parameters and I dot source the functions in my profile. Each time I open PowerShell, the list of functions in my profile scrolls by (If like me, you frequently forget the exact names of your functions/files You'll appreciate this as over time as the number of functions start to pile up).
Old but still relevant.
I work with modules with "Import-Module ", this will import the module in the current powershell session.
To avoid keep in cache and to always have the last changes from the module I put a "Get-Module | Remove-Module" that will clear all the loaded modules in the current session.
Get-Module | Remove-Module
Import-Module '.\IIS\Functions.psm1'
I have both Sybase and MSFT SQL Servers installed. There is a time when Sybase interferes with MS SQL because they have they have some overlapping commands.
So, I need two scripts:
A) When runs, script A backs up the current path, grabs all paths that contain sybase or SYBASE or SyBASE (you get the point) in them and move them all at the very end of the path, while preserving the order.
B) When it runs, script B restores the path from back-up.
Both script a and script b should affect the path immediately. So, if a.bat that calls patha.ps1, pathb.ps1 looks like so:
#REM Old path here
call patha.ps1
#REM At this point the effective path should be different.
call pathb.ps1
#REM Effective old path again
Please let me know if this does not make sense. I am not sure if call command is the best one to use.
I have never used P.S. before. I can try to formulate the same thing in Python (I know S.O. users tend to ask for "What have you tried so far"). Well, at this point I am VERY slow at writing anything in Power Shell language.
Please help.
First of all: call will be of no use here as you are apparently writing a batch file and PowerShell scripts have no association to run them by default. call is for batch files or subroutines.
Secondly, any PowerShell script you call from a batch file cannot change environment variables of the caller's environment. That's a fundamental property of how processes behave and since you are calling another process, this is never going to work.
I'm not so sure why you are even using a batch file here in the first place if you have PowerShell. You might just as well solve this in PowerShell completely.
However, what I get from your problem is that the best way to resolve this is probably the following: Create two batch files that each set the PATH appropriately. You can probably leave out both the MSSQL and Sybase paths from your usual PATH and add them solely in the batch files. Then create shortcuts to
cmd /k set_mssql_path.cmd
and
cmd /k set_sybase_path.cmd
each of which now is a shortcut to a shell to work with the appropriate database's tools. This is how the Visual Studio Command Prompt works and it's probably the cleanest solution you have. You can use the color and prompt commands in those batches to make the two different shells distinct so you always know what environment you have. For example the following two lines will color the console white on blue and set a prompt indicating MSSQL:
color 1f
prompt MSSQL$S$P$G
This can be quite handy, actually.
Generally, trying to rearrange the PATH environment variable isn't exactly easy. While you could trivially split at a ; this will fail for paths that itself contain a semicolon (and which need to be quoted then). Even in PowerShell this will take a while to get right so I think creating shortcuts specific to the tools is probably the nicest way to deal with this.