Like any good thing, catching and storing errors will require some planning upfront. What type of errors could your script encounter? Are there any actions the script could take when an error has happened? What do you want to do with the error after it has occurred?

Once you have answered these questions, you can begin coding a solution to catch and store any errors. The starting point for your script will be the PowerShell try, catch functionality. The try block will be the action taken in your script, and the catch block will be used if an error is encountered during the try action. Different error types can be specified and stored in variables in the catch block. The last error message that was encountered by the script is stored by default in $_ and can be stored in a variable. The example below stores the error in the $LastException variable.

Additionally, you can include multiple catch blocks, to handle specific types of errors and then a general catch block for every other error. The example below looks for an ItemNotFoundException and stores the error in an $ItemNotFound variable.

try
{
    Write-Host "Here are your action steps."
}
#This will catch an Item Not Found Exception
catch [System.Management.Automation.ItemNotFoundException] {
    $_.Exception.GetType().Name
    $ItemNotFound = $_.Exception.GetType().Name
}
catch
{
    Write-Host "Error: $($_)"
    $LastException = $_
}

if ($LastException)
{
    Write-Host "An error has occurred, the error text is $($LastException)."    
}

These examples should give you a good start toward handling errors in your PowerShell scripts. There are many options for additional handling and adding catch blocks to find and store additional error messages. Thank you for reading!

So let’s say you have forked a github repository so you can contribute some code or documentation. You create a branch of your fork, make your changes, and prepare to make a pull request. But you realize, the original repository has moved on since your fork, meaning, other developers have made commits to it that you don’t have on your local copy. You will need to add those changes to your local copy before making a pull request.

Rebasing will get all the commit to the original repository while saving the changes you made to your local copy. Rebasing will also rewrite the commit history on your forked branch, so it puts your commit at the beginning. This makes for a linear commit history in the original repository.

Keep in mind that rebase should not be done on a public repository where other developers are making commits. Since rebase will rewrite the commit history, it will be confusing other developers working on a project if the entire commit history was rewritten. If, however, you are the only person working on a particular repository, such as a fork, rebase is perfectly applicable and should be used keep a linear commit history.

Once your commits are complete, go to your terminal and change directory to your project. Then follow the list of commands below to rebase from the original repository.

Configure the upstream repository in your project. Change the url to the original repository.

git remote add upstream url

Check that the upstream repository is configured.

git remote -v

Get the original repository contents.

git fetch upstream

Checkout your branch and rebase it with the original repository. Replace main in the checkout statement with your branch name.

git checkout main
git rebase upstream/main

Push the rebased repository to your remote forked branch. The --force option may be necessary if there are conflicts between the local and remote repositories. Replace main with your branch name.

git push origin main --force

Now you are ready to make a pull request and merge your changes with the original repository.

(refusing to allow a Personal Access Token to create or update workflow `.github/workflows/build_main.yaml` without `workflow` scope)

Frustrating right! Well, fortunately this is easy to fix by following the steps below.

1. Login to GitHub
2. Go to Settings and choose Developer Settings
3. Choose Personal Access Tokens
4. Click the link on the personal access token used for your project
5. Check the box beside workflow and click Update Token
6. Click Generate new token and create a save the new token
7. Change the token in your project to the new one with the workflow scope Note that you may not need to do steps 6 and 7, it’s best to try your push again after updating to confirm.

After updating or generating a new token the workflow scope will be allowed and you can continue on your way.

Cloning a Repository

Cloning a repository is the git term for downloading a remote project to your local machine. You can do this with git clone repourl, just replace “repourl” with the url of the repository you want to clone. Doing this on a fork of the original repository is a good idea so you are not trying to commit changes directly to the main branch. Once the command completes, the project files will exist in your local folder. The git metadata, which is how git keeps track of changes, is hidden in the .git folder. To see the metadata files, show hidden files in your git repository folder.

Making Changes

Once you have a current copy of the repository on you local machine, you are ready to begin making changes. After you make changes to a file, make a record of it with git add filepath, and replace “filepath” with the path to the changed file. Repeat git add until you have a record of all the changed files. Then run git status and make sure all the changed files show up.

Commit Changes

Once your changes are done, it’s time to commit. I know what you’re thinking, but backing out of commits in git is painless! So don’t worry if you commit by mistake. In git, a commit is the record of changes you want to add to the online repository, a line in the sand if you will, that says, I own these changes. If you desire, you can make a commit for each file change; this gives you the option to back out a single change if needed. But if you are brave, you can commit all your changes in one go! The git commit -m "Commit Message" will commit the changes, then the only thing left is to push them to the online repository.

Pushing Changes

After committing all your changes, they are ready to be pushed to the online repository. The git push repo branch will achieve this, but note that you will need to change repo and branch to the applicable repository and branch for your setup. If you are working from a fork that you cloned, using “origin” as your repo will likely work. This will push the changes to the repository defined as origin in your git metadata. If you are pushing to a branch of this repository, enter this after repo, but if you are not branching, enter main to push to the main branch. If you are in doubt, open your github repository in the browser and look at the different branches. If no branches exist, just push to the main branch.

This guide demonstrated how to use command line git to clone a repository, add changes, commit changes, and push to an online repository. Learning git can be daunting, but don’t give up! This guide is a great starting point and should encourage you to keep expanding your knowledge.

The first thing to know is that the terminal uses an environment variable called $PATH to determine where to look for installed commands. Since this is a variable, it is specific to your environment setup. There are two possible files where the terminal will look for your environment variables. Both are located in you home folder or ~/. To get to this folder in the terminal use cd ~/ or in Finder Cmd+Shift+G. The two files are named .zshrc or .bash_profile, the one in use will depend on which version of the shell you are using. To find this out use echo $SHELL in the Terminal. For zsh the output is /bin/zsh and for bash it is /bin/bash.

Now that you know what shell you are using, you know where to look for your environment variables. Open Terminal and change the directory to /~. Then use the cat command to display the contents of the file in Terminal. If you are using bash, make sure to substitute the bash file for the zsh file in the commands.

cd ~/
cat .zshrc

Now you know what is in your file and you should have an idea of what you want to add. To add to the file use the export command in the terminal along with the path to the files you installed. This example will use zsh and ruby 3.0.0 that was installed using homebrew. Keep in mind that the path and application will vary based on what is being installed and how you installed it.

echo 'export PATH="/usr/local/opt/ruby/bin:/usr/local/lib/ruby/gems/3.0.0/bin:$PATH"' >> ~/.zshrc

Once the command completes refresh your terminal session by using source ~/.zshrc or by closing the terminal and opening it again. Now when you run your command it should complete without the “Command Not Found” error. You may be asking, where do I find out where my is installed so I know what to add to my PATH. The answer to this depends on how the package was installed, and what version it is. In the logs from your package manager it will likely have the install location. If this is not available try searching for the default install location for your package manager and look there. If you still can’t find it, try installing the package again and see if the logs will tell you where it put the files.

Please note that powershell modules are not compatible with every powershell version, remember to check the module prerequisites before installing it on the desired computer.

Prerequisites

Here are the prerequisites you will need to complete the steps in this guide.

A Windows computer, connected to the internet. The name of the powershell module you want to install. The path where you will save the module on your computer.

Installing the Module

The first step for installing a PowerShell module on an offline computer is to download it with a computer that is connected to the internet.

1. In the Start menu search for the Windows Powershell application and open it.
2. On the command line type Save-Module -Name ModuleName -Path “FilePath” and Enter to run the command. Remember to replace ModuleName and FilePath with the values needed for your use case.
3. The module will now be saved into the folder defined in the -Path parameter. Browse to this location in File Explorer.

The next step is to move the module folder to the offline computer and import it into powershell.

1. Copy the folder you located in step 3 and paste it on the offline computer in the following location, C:\Program Files\WindowsPowerShell\Modules.
2. On the offline computer, search for Windows PowerShell in the Start menu and open it.
3. On the command line type Import-Module -Name ModuleName and Enter to run the command. Please note that the name entered on the command line needs to match the folder name copied in step 4.

The module has now been installed on the offline computer, congratulations!

$filelist = (Get-ChildItem “C:\FilePath\*.*” | foreach-object {$_.name})
foreach ($file in $filelist)
{
$newname = ‘customString’ + $file + ‘.file’
Rename-Item “C:\FilePath\$file” $newname -verbose
clear-variable newname
}

Begin by searching for the file you want to rename. The Get-ChildItem command will find the list of files and pass it to foreach-object. This is all stored in the $filelist variable. Then a foreach loop is created in which a new file name is given to each file. The $newname variable will control how the file is named with the $file section being the original file name. This original file name can be replaced with whatever is needed for your circumstance. Dates and times can also be added to the name by using Get-Date and formatting the date and time as desired. The new name is then passed to the Rename-Item command to perform the rename operation. Finally the newname variable is cleared so it can be used in the next loop.

First, store each file contents in memory using variables and the Get-Item command. Then compare them with an if statement using the file.Length command. The space in the else rackets can be used to take appropriate action if the file lengths do not match.

$file1 = Get-Item ‘C:\FilePath\File1.file’ -Verbose
$file2 = Get-Item ‘C:\FilePath\File2.file’ -Verbose
If ($file1.Length -eq $file2.Length)
{ Write-Host “File Sizes Match” }
else
{ Write-Host “File Sizes Do Not Match” }

The first step is to store the service name in the variable $ServiceName. Then you can use another variable to store the service information which contains the status information. The Get-Service command can be used to retrieve this information.

Then, using an if statement, you can compare the service info status to a static value. In the example, the service info status is checked against the value Running which determines whether is started and running. The actions can then be taken on the service such as starting it or alerting the appropriate parties. In the example, the script attempts to start the service, then performs a refresh of the service information and writes the new status to the console log.

$ServiceName = ‘Service’
$ServiceInfo = Get-Service -Name $ServiceName
if ($ServiceInfo.Status -ne ‘Running’) {
write-host ‘service is not started, starting service’
Start-Service -Name $ServiceName -verbose
$ServiceInfo.Refresh()
write-host $ServiceInfo.Status
}
write-host ‘all done’

This script will remove files by last write time, which is the last date and time the file was modified.

$Now=Get-Date
Get-Childitem C:\FilePath\*.* | Where-Object { $_.LastWriteTime -lt $Now.AddDays(-30) } | Remove-Item -Verbose

The first step is to get the time you want to use as the baseline for the delete, this is what you will compare against when telling the script what files to remove. In the example, this date and time is stored in the variable $Now. The Get-Date command will retrieve the date and time when the script is run.

The next step is to get a list of files that are candidates for removal. This is done with the Get-ChildItem command and the file path. This information is sent to the Where-Object command which determines which files meet the criteria. In the example, last write time is used along with $Now.AddDays(-30) which subtracts 30 days from the current date. Any files where the last write time is more than 30 days old are then sent to the Remove-Item command and deleted.

To perform this operation, use the code here.

$SortValues = Get-Content -Path C:\FilePath\FileName.file | ForEach-Object -Process {[int]$_} | Sort-Object
$SortValues | ForEach-Object {$_.ToString(“0000000000000000”)} | Out-File -FilePath C:\FilePath\SortedFileName.file

The code assumes that the values are stored in a file, with the first command retrieving the data from the file. This data is then sent to the ForEach-Object command which casts the string values as integers and then sorts each value in ascending order. This data is stored in the variable $SortValues which can then be used to create an output file in the second command.

The second command takes the data stored in the $SortValues variable and makes sure each value is 16 characters, meaning it will add leading zeroes where necessary. Please note, that this step is not necessary, if you want to simply output the values as they are to a file, this section can be removed, leaving the Out-File command. The Out-File command then creates an output file with the values sorted by number.

Get-ChildItem “C:\FilePath\*FileName.file” | Get-FileHash | Group-Object -property hash | Where-Object { $_.count -gt 1 } | ForEach-Object { $_.group | Select-Object -skip 1 } | Remove-Item -Verbose

The first step is to get a list of the files that are duplicated, this is done with Get-ChildItem and the path and name of the files. This list is then sent to the Get-FileHash command which retrieves the file hash for each file in the list. The file hashes are then grouped by the hash number with Group-Object so the duplicate file hashes will be next to each other in the list. This is important for the next step.

The grouped list is then sent to Where-Object which counts the list for file hashes where the value is greater than one. This will identify only the duplicated files from the list. The grouped objects are then sent to ForEach-Object which creates a loop to run through each set of duplicate files. In each duplicate object set, one file is skipped and not retained in the list that is sent to Remove-Item to delete the file. Now duplicates should have been removed.

When performing an ad hoc transfer, it is easy to see when a transfer fails and take action to correct it. But when using automation for file transfers, this becomes difficult. How do you know when a transfer fails and how it should be corrected? A first step toward this is evaluating the exit code of the ftp script. This would indicate if the script completed all steps successfully or not. It will not indicate exactly what failed, this will require further investigation. The exit codes are zero for success and one for failure. There is some variation in exit codes between ftp clients but zero is always success and one is always a type of failure. Evaluating the exit code for non-zero values would indicate whether a script failed and needs further review.

To evaluate the exit code, add the following line to the end of a shell script in Windows after the ftp commands have completed.

IF %ERRORLEVEL% EQU 0 Echo Success > “Path to File”

This line will check if the exit code is zero and write the word “Success” to a defined file. Evaluating the exit code is not limited to this type of interaction, using the if statement above, any number of actions can be performed after the exit code is evaluated. For instance, if the exit code is not equal to zero a message could be sent to indicate further review is needed. The exit code could also be consumed by another monitoring tool which would allow for automated alerting in cases where many transfers need to be evaluated. The options are only limited to your imagination but evaluating the exit code is the entry point for knowing if a file transfer was successful.

But what if multiple files are needed before acting? The Test-Path command can accept an array with each path being separated by commas. While checking the result for a single file is a simple True/False statement, checking the result of a Test-Path array is more difficult. When the result of a Test-Path array is stored in a variable, it stores the result of each file path check. All the file paths may evaluate to True, False, or a combination of both. This means, when checking the result, it is necessary to accept one desired outcome and discard all others.

For example, to accept only an outcome where all file paths evaluate to True, the -notcontains $false modifier can be used on Test-Path. This will ignore any outcomes that are false meaning the whole Test-Path statement will only be True when all file paths in the array are True. The same logic can be used in reverse if the desired outcome is for all of the paths to be False.

Here is an example of how to use an array with Test-Path. In this example the $result variable will only be true if all paths in the array exist.

$filecheck = “File Path 1”, “File Path 2”, “File Path 3”
$result = ($filecheck | Test-Path) -notcontains $false

To set a home directory, the — homedir switch can be used on the command line followed by the path to the home directory. Typically, this will be a copy of gnupg folder after the applicable keys have been created or imported and trusted. This type of setup is could be effective in a single-use context, but not in a scenario where file decryption needs to happen repeatedly. The reason for this is because of how the gpg agent interacts with the home directory. The gpg agent starts when it is called and ends when the interaction has ceased. But when using a home directory, the normal termination of the gpg agent is not allowed to occur and can leave the agent thread running in the background. This can have unintended consequences such as interrupting repeated processes that are attempting to use the same home directory.

The simplest solution to this is temporary home directories. Recursively copying, using, and then removing a home directory will reliably start, engage, and end the gpg agent thread, allowing for repeated use. The removal of the home directory indicates to the gpg agent that the process is complete, and it can end.