I am working on PowerShell script that requires me to pass string as param. The string is a comma seperated list of user names. I get the error when i have 100+ user names. But i get no error if the string has less then 100 users. See below. I have tried to pass this value using array with no luck. What is the character limitation for this param and how can i solve this. I am using this in ServiceNow Run PowerShell script. That value of the parameter is passed by ServiceNow using a comma seperated value.
Param(
[string]$itil_users_a = "A.Syafiq,Aaron.Brown,Aaron.Reynnie,Abd.Jalil,Abdu.Hijazi,Abdul.Onny,Abdullah.Ammar,Abel.Muataco"
)
You may be running into the maximum length for command lines - 8191 chars. See this KB article on max command line length.
You can use pipe to get around this.
I can insert a million rows to sqlite3.exe using pipe.
Rather than sqlite.exe .\ex1.db $sql which will return error. You can use this: $sql | sqlite.exe .\ex1.db
The $sql variable can have more than a million rows (so it's more than 8191 characters).
Related
I am writing a program prog.exe that retrieves all arguments that are passed to it (in the form of a "sentence", not standalone arguments).
I just realized that in some cases only part of the line is retrieved, and this is when there are #parameters:
PS > ./prog.exe this is a #nice sentence
Only this, is and a are retrieved. In case I do not use # I get all of them. I presume this is because everything after the # is interpreted by Powershell as a comment.
Is there a way to retrieve everything that is on the command line?
If this makes a difference, I code in Go and get the arguments via os.Args[1:].
You can prevent PowerShell from interpreting # as a comment token by explicitly quoting the input arguments:
./prog.exe one two three '#four' five
A better way exists, though, especially if you don't control the input: split the arguments into individual strings then use the splatting operator # on the array containing them:
$paramArgs = -split 'one two three #four five'
./prog.exe #paramArgs
Finally, using the --% end-of-parsing token in a command context will cause the subsequent arguments on the same line to be passed as-is, no parsing of language syntax:
./prog.exe --% one two three #four five
My batch script gets a url passed into it with a number of query params, one of which will be browser=chrome, browser=firefox etc.
I'm trying to do a substring comparison to check if it has browser=chrome in the url:
if not "x%url:browser=chrome=%"=="x%url%" (
start chrome
)
This doesn't seem to work, I think because of how batch reads = signs, any ideas how I can do this? I can't just check for "chrome" as this could occer elsewhere in the query params.
This question already has answers here:
Export-CSV exports length but not name
(6 answers)
Closed 4 years ago.
Operating System - Windows 10
Powershell version - 5.1.15063.1088
Ok, I'm really trying hard to think logically what can be wrong with this PowerShell script, but apparently can't get an idea and asking for some help. So here is what I'm trying to do, simple as 1+1
If I understood the tutorial correctly, creating an array in PowerShell is like this:
$someVariable = "PowerShell", "MowerShell", "HowerShell", "ZowerShell"
Then I'm simply trying to write this thing to csv file with comma as delimeter, but firstly give it a try in the console output
$someVariable | ConvertTo-Csv -NoTypeInformation
According to PowerShell 5.1 official documentation
...Specifies a delimiter to separate the property values. The default
is a comma (,).
So no additional writing that I would like to use comma as delimiter is not required. Once the command Write-Host $someVariable is executed, I see this weird output:
"Length" "10" "10" "10" "10"
What is this? Am I suppose to see the values of my variable separated with simple comma? So from the numbers I can guess that scripts calculates the amount of alphabet letters in each word -
P o w e r S h e l l
contains 10 letters.
Is this the suggested way to calculate the amount of letters in the string (in case I get PowerShell task on my next job interview) using ConvertTo-Csv command?
Writing this funky data to the csv file itself leads to more unexpected results:
Now I'm completely lost what those numbers are...
Is this possible to write my strings as STRINGS to the csv file in one line rather then silly numbers?
The desired output is this entry as headers in the csv file:
"PowerShell","MowerShell","HowerShell","ZowerShell"
The output reads "Length", and has a series of 10's. Each of your strings are 10 characters long (the double quotes aren't factored in).
Length can be calculated many ways. I wouldn't say there is one suggested way, only the ways that fit what you're trying to do.
To get the literal text of what you posted (no headers, etc.) in a csv, try:
$someVariable | Out-File foo.csv
I'm attempting to write a Twitter Powershell script that will use community created interfaces PoshTwitter with the Twitter API to attempt and find a list of followers who are potential spammers.
I have a feeling that my problem lies not with the particular cmdlet I'm calling (Get-TwitterFollowers), but rather with the difference between assigning a variable:
If I try this:
$rawFol = get-twitterfollowers -page $page -raw 1
$rawFol is different than if I do this:
get-twitterfollowers -page $page -raw 1 > .\page$page.txt
$rawFol = gc .\page$page.txt
The Get-TwitterFollowers cmdlet returns an XML file converted to string.
What things can I try to determine the differences between these two assignments? They look like they'd result with same content.
The difference you're seeing is how powershell handles new lines in strings. When calling the get-twitterfollowers CmdLet, it is either returning a single string or an array of strings. My guess by your description is that it returns a string. So the $rawFol variable will have a single string value. Any new lines are simply embedded into the string value.
The second command you write the return to a file. Now all of the newlines in the string are represented as lines in the file. Later when you call gc on that file, each line will be returned as a separate string. So the $rawFol variable will now have an array of strings.
Im trying to run some logparser commands from powershell but Im having issues with passing the arguments across correctly, heres the excert from my script;
d:\scripting\smtplogs\logparser\logparser.exe "SELECT TOP 50 Receiver, COUNT() INTO %TMPOutput%\TopReceiversNDRALL.gif FROM %TempDir%\PostAll.log WHERE Sender LIKE '<>' AND Receiver NOT LIKE '%%go-fmtopper%%' GROUP BY Receiver ORDER BY COUNT() DESC" -i:TSV -iSeparator:space -headerRow:OFF -iHeaderFile:"header3.tsv" -lineFilter:"+10." -o:CHART -chartType:ColumnClustered -config:MyScript.js -chartTitle:"Receivers for NULL messages ALL for %DateGraph%"
Ive read loads about encapsulating arguments but cant seem to figure out how to make this work!
Any help that you guys could provide would be very appreciated.
Thanks
For a complex string parameter, try to pass the argument using powershell here-strings so that you wouldn't have to worry about escaping single/double quotes
UPDATE1: I couldn't get the fomratting working so here is the screenshot.
UPDATE2: I was able to format the code finally.
d:\scripting\smtplogs\logparser\logparser.exe #"
SELECT TOP 50 Receiver, COUNT()
INTO %TMPOutput%\TopReceiversNDRALL.gif
FROM %TempDir%\PostAll.log
WHERE Sender LIKE ''
AND Receiver NOT LIKE '%%go-fmtopper%%'
GROUP BY Receiver
ORDER BY COUNT() DESC"
-i:TSV
-iSeparator:space
-headerRow:OFF
-iHeaderFile:"header3.tsv"
-lineFilter:"+10."
-o:CHART
-chartType:ColumnClustered
-config:MyScript.js
-chartTitle:"Receivers for NULL messages ALL for %DateGraph%
"#
Make sure that you add a new line between the here-string monikers #" and "#.
FYI, if you don't need any PowerShell variable expansion then you are better off using single quoted here strings. For example the following double quoted here string might cause you some grief:
#"
$(get-process <some_core_os_process> | stop-process)
"#
where the following is harmless:
#'
$(get-process <some_core_os_process> | stop-process)
'#
It's not likely your here string would contain something so obvious but a simple $f would resolve to nothing i.e. it would disappear from the original string. Unless, of course, $f was defined and set to something other than null or empty.