PowerShell - Add-Content- Unable to add multiple vars to a file - powershell

I'm trying to add an expression to a log file which contains Date,Time some data separated by ";". Unfortunately I get an error every time I change the position of the items in the -value brackets.
Whats seems to be wrong?
This is the code :
Add-Content -path C:\...\outlog.txt -Value($Date + ';' + $Time + ';Checked;' + $strFileName)
This is the error :
Cannot convert argument "1", with value: ";", for "op_Addition" to type "System.TimeSpan": "Cannot convert
value ";" to type "System.TimeSpan". Error: "String was not recognized as a valid TimeSpan.""
At C:\...\Untitled1.ps1:8 char:64
+ ... \outlog.txt -Value($($Date + ';' + $Time + ';'+ $str))
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodException
+ FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument

Try this -
Add-Content -path C:\...\outlog.txt -Value("$Date; $Time; Checked; $strFileName")
If you look at get-help Add-Content -full, and look at the -value parameter, you will see -
-Value <Object[]>
Specifies the content to be added. Type a quoted string, such as "This data is for internal use only", or
specify an object that contains content, such as the DateTime object that Get-Date generates.
You cannot specify the contents of a file by typing its path, because the path is just a string, but you can
use a Get-Content command to get the content and pass it to the Value parameter.
Required? true
Position? 1
Default value None
Accept pipeline input? True (ByPropertyName, ByValue)
Accept wildcard characters? false
It says that it expects a quoted string or an object that contains content. It was missing in your case and hence the + operator was trying to add $date and time.

Related

Powershell Registry String to Workable Date

Cannot convert string format to date using parse exact.
Registry contains the following string value:
2022-10-18T12:40:25
I need to convert this string to a date field in order to count number of days since (compared to today).
$startdate =
Get-ItemProperty -Path 'HKLM:SOFTWARE\Adobe\Acrobat Distiller\DC\Installer\' |
select-object 'Dummy'
[datetime]::parseexact($startdate,'dd/MM/yyyy HH:mm',$null)
$today = (([datetime]::Now))
$x = New-TimeSpan -Start $startdate -End $today
"$($x.days) $("days have passed since") $($startdate)"
Cannot find an overload for "parseexact" and the argument count: "3".
At line:2 char:1
+ [datetime]::parseexact($startdate,'dd/MM/yyyy HH:mm',$null)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodException
+ FullyQualifiedErrorId : MethodCountCouldNotFindBest
New-TimeSpan : Cannot bind parameter 'Start'. Cannot convert value "#{dummy=2022-10-18T12:40:25}" to type "System.DateTime". Error: "Cannot convert the "#{dummy=2022-10-18T12:40:25}" value of type
"Selected.System.Management.Automation.PSCustomObject" to type "System.DateTime"."
At line:5 char:26
+ $x = New-TimeSpan -Start $startdate -End $today
+ ~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [New-TimeSpan], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.NewTimeSpanCommand
days have passed since #{dummy=2022-10-18T12:40:25}
Your primary problem is that you need to use -ExpandProperty, if you use Select-Object, or you can use simple property access:
Select-Object (select) by default returns a [pscustomobject] instance that has the requested properties - even when you're only asking for a single property. To get only that property's value, use the -ExpandProperty parameter instead of the (possibly positionally implied) -Property parameter - see this answer for details and alternatives, notably the ability to simply use (...).SomeProperty
Therefore, the simplest solution is:
$startdate = (
Get-ItemProperty 'HKLM:SOFTWARE\Adobe\Acrobat Distiller\DC\Installer'
).Dummy
Or, in PSv5+, using Get-ItemPropertyValue:
$startdate =
Get-ItemPropertyValue 'HKLM:SOFTWARE\Adobe\Acrobat Distiller\DC\Installer' Dummy
As for then parsing the resulting string into a [datetime] instance:
The format string you're passing to ::ParseExact(), doesn't match your input string, and TheMadTechnician's answer shows how to fix that (see this answer's bottom section for further considerations).
However, you can more simply use a [datetime] cast, which recognizes your string format as-is, irrespective of what culture is currently in effect:
[datetime] '2022-10-18T12:40:25'
In essence, PowerShell translates the above into the following ::Parse() call:
[datetime]::Parse('2022-10-18T12:40:25', [cultureinfo]::InvariantCulture)
In general, for full robustness when using format strings, it is best to escape :, /, and . (if present) with \, so as if they are to be interpreted literally, i.e by only matching literally during parsing and being included literally when formatting output (by default, they're considered placeholders for the target culture's separators):
[datetime]::ParseExact(
'2022-10-18T12:40:25',
'yyyy-MM-ddTHH\:mm\:ss', # \-escaping ensures literal matching
[cultureinfo]::InvariantCulture
)
Note: In this particular case, [cultureinfo]::InvariantCulture alone would be sufficient for robustness, given that this culture uses : as the time separator.
You get an error because your second argument doesn't match the format of the datetime.
[datetime]::parseexact($startdate,'yyyy-MM-ddTHH:mm:ss',$null)

How to assign and reference environment variables containing square brackets in Powershell

When the PSDrive is not specified, the following works:
${[foo]}="bar"
echo ${[foo]}
But the following does not work
$env:${[foo]}="bar"
At line:1 char:1
+ $env:${[foo]}="bar"
+ ~~~~~
Variable reference is not valid. ':' was not followed by a valid variable name character. Consider using ${} to delimit the name.
At line:1 char:6
+ $env:${[foo]}="bar"
+ ~~~~~~~~~~~~~~
Unexpected token '${[foo]}="bar"' in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : InvalidVariableReferenceWithDrive
${env:[foo]}="bar"
Cannot find path 'env:[foo]' because it does not exist.
At line:1 char:1
+ ${env:[foo]}="bar"
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (env:[foo]:String) [], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound
The following works, though I am curious if there's short hand syntax for it:
Set-Item -LiteralPath env:${[foo]} -Value "bar"
Get-Item -LiteralPath env:${[foo]} | % {$_.Value}
However the following does not work:
Set-Item -LiteralPath env:${[foo]2} -Value "bar"
Set-Item : Cannot process argument because the value of argument "name" is null. Change the value of argument "name" to a non-null value.
At line:1 char:1
+ Set-Item -LiteralPath env:${[foo]2} -Value "bar"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:String) [Set-Item], PSArgumentNullException
+ FullyQualifiedErrorId : SetItemNullName,Microsoft.PowerShell.Commands.SetItemCommand
Written as of PowerShell Core 6.2.0
The reason is that PowerShell treats the following:
${<drive>:<name>}
as if you had specified:
Get-Content -Path <drive>:<name> # or, with assignment, Set-Content -Path ...
This notation - though often used with the Env: drive (e.g., $env:Path) - is little-known as a general paradigm named namespace variable notation, which is explained in this answer.
The problem is the use of -Path rather than -LiteralPath, because -Path interprets its argument as a wildcard expression.
Therefore, the [foo] in ${env:[foo]} - rather than being used as-is - is interpreted as a wildcard expression that matches a single character that is either f or o ([foo] is a character set or range ([...]) that matches any one of the (distinct) characters inside - see about_Wildcards).
On assigning to ${env:[foo]}, the logic of Set-Content -Path requires that a wildcard-based path resolve to something existing, even though you're generally not required to explicitly create environment variables; e.g., ${env:NoSuchVarExistsYet} = 'new' works just fine.
Workaround:
Use double(!)-`-escaping of the wildcard metacharacters:
# Namespace variable notation only works with if you
# double(!)-backtick-escape the wildcard metacharacters:
# Assign to / implicitly create env. var '[foo]'
${env:``[foo``]} = 'bar'
# Get its value.
${env:``[foo``]}
Note:
Escaping shouldn't be required at all, because there is no good reason to treat paths that conceptually identify a given, known item as wildcard expressions - see GitHub issue #9225.
That double `-escaping is needed is an added quirk - see GitHub issue #7999.
Another workaround - one that doesn't involve escaping - is to use
Set-Content -LiteralPath env:[foo] bar and Get-Content -LiteralPath env:[foo], but that is both verbose and slow.
As for the other syntax variations you tried:
$env:${[foo]}="bar"
Since your variable reference isn't {...}-enclosed as a whole (except for the initial $), the token that follows the : is only allowed to contain characters that do not require escaping - and $, { and } all violate that rule.
{...}-enclosing the entire path - ${env:[foo]} - solves the syntax problem, but runs into the problem detailed above.
Set-Item -LiteralPath env:${[foo]} -Value "bar"
This does not work in general, because string expansion is applied beforehand here - it is as if you had passed "env:${[foo]}": the reference to a (regular) variable named ${[foo]} is expanded (replaced with its value) and in effect appended to literal env:, before handing the result to Set-Item.
If such a regular variable doesn't exist, what Set-Item sees is just env: (because non-existent variables default to $null, which becomes the empty string in a string context), which causes an error due to the lack of variable name.
By contrast, the following would set an environment variable named unrelated instead:
# Create a regular variable literally named '[foo]'.
${[foo]} = 'unrelated'
# !! The following sets env:unrelated, i.e., env. var 'unrelated',
# !! due to the string expansion that is performed on the -LiteralPath
# !! argument up front.
Set-Item -LiteralPath env:${[foo]} bar
$env:unrelated # -> 'bar'
The same applies to Get-Item -LiteralPath env:${[foo]} and
Set-Item -LiteralPath env:${[foo]2} -Value "bar".

Function prompts value for Add-Content and treats .txt file as directory

I am writing a PowerShell script for creating error status files. The info I need is defined in a global variable ($info) and is returning the correct string I need it to. The type is System.String.
function Add-Fail
{
$date = Get-Date -f "yyyy-MM-dd"
Add-Content \\Path\To\FailMonitor\${date}.txt $info
}
I have also tried passing the variable like this:
function Add-Fail ($info)
{
$date = Get-Date -f "yyyy-MM-dd"
Add-Content \\Path\To\FailMonitor\${date}.txt $info
}
and calling it like this where info is a string:
Add-Fail($info)
and this
Add-Fail -info $info
For both of these cases, I get the same output which is asking for a value. If I input values, it keeps prompting me for the next one in an infinite array. If I don't input one and just hit enter, it gives me an error that has no information, and even refers to my Add-Content line on the complete wrong line number.
Output (Edited out username):
cmdlet Add-Content at command pipeline position 1
Supply values for the following parameters:
Value[0]: 1
Value[1]: 2
Value[2]:
Add-Content : The filename, directory name, or volume label syntax is incorrect.
At C:\Users\********\Documents\Workspace\Error_Monitor.ps1:40 char:5
+ Add-Content \\nserver\scsi\HPQ\FailMonitor\$date\
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (\\nserver\scsi\...tor\2016-10-18\:String) [Add-Content], IOException
+ FullyQualifiedErrorId : GetContentWriterIOError,Microsoft.PowerShell.Commands.AddContentCommand
As you can see, it refers to my date as a directory. For reference, my Add-Content expression is on line 45, char 5. It sees my .txt file as a directory and treats it as such. The text file is not a directory at all. It isn't a variable problem either as I have cleared the variables. I have also tried no brackets around the date, but that didn't work either.
Why is PowerShell behaving like this? What am I missing?

powershell search function with regular expression

the text file content is:
In this script, we have the following variables:
$input_path to hold the path to the input file we want to parse
$output_file to hold the path to the file we want the results to be stored in
$regex to hold the regular expression pattern to be used when the strings are being matched.
The select-string cmdlet contains various parameters as follows:
-Path which takes as input the full path to the input file
-Pattern which takes as input the regular expression used in the matching process
AllMatches which searches for more than one match (without this parameter it would stop after the first match is found) and is piped to $.Matches and then $_.Value which represent using the current values of all the matches.
Code:
$replace_file=#{}
$replace_text_file_path="EMS_checksystem_script\replace.txt"
$replace_file= gc $replace_text_file_path
$result=0
$valr=read-host "please enter the key word"
for($i=0;$i -lt$file_context.length;$i++)
{
$result=$replace_file[$i] -match $valr
if( $result -eq 1)
{
$replace_file[$i]
}
}
Result:
key word: *pression
Bad argument to operator '-match': parsing "*pression" - Quantifier {x,y} following nothing..
At line:11 char:37
+ $result=$replace_file[$i] -match <<<< '*pression'
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : BadOperatorArgument
key word: pression*
key word: press*on
NO result
How can use the press*on and *pression keywords to search?
Read up on regex. You can test regex here > http://www.regexr.com/
Your keyword is wrong, use "." to match any character and "*" to match any number of the previous character.
PS C:\>'expression' -match ".*pression"
PS C:\>True

Weird PowerShell Exec Output Capture Behavior

I'm writing a simple PowerShell script that handles the output of mkvinfo. It captures the output of mkvinfo, stores in a variable $s and does some post-processing on $s. The strange part is while $s has content, I can't extract a substring from it.
The error message I'm getting was:
Exception calling "Substring" with "1" argument(s): "startIndex cannot be larger than length of string.
Parameter name: startIndex"
This is a sample code:
$filePath = $folder + $file.name
$mkvinfoExe = "C:\mkvinfo.exe"
$s = & $mkvinfoExe $filePath
$s | out-host
$s.Substring($s.Length-1) | out-host
Are you sure $s is a string and not an array? If it is an array, $s.Length will be the number of elements in the array and you could get the error that you are getting.
For example:
PS > $str = #("this", "is", "a")
PS > $str.SubString($str.Length - 1)
Exception calling "Substring" with "1" argument(s): "startIndex cannot be larger than length of string.
Parameter name: startIndex"
At line:1 char:1
+ $str.SubString($str.Length - 1)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentOutOfRangeException
Just found out because mkvinfo outputs multiple lines, $s is actually a String array (or List?). Switching to $s[0].Substring($s[0].Length-1) solves it.