Emulate bash ls -ltr pipe grep in PowerShell

I use the script below to to emulate bash

ls -ltr /www/root/*html| grep 'string' | grep 'narrower search string'

I open up the results in notepad - because it is so tough to cut and paste from the PowerShell terminal.

It works ok when there are two parameters - however it does not work well when I have just one parameter, like:

ls -ltr /www/root/*html| grep 'string'

I know how to use @ARGS in bash. However have not seen anything comparable in PowerShell. I don't see any kind of array to verify the line arguments in PowerShell.

param( 
[parameter()]
[string] $param1 = $null ,
[string] $param2 = $null 
)

$makecurrent = '(dir sample_file.txt).LastWriteTime = Get-Date'

$timestr = get-date -f 'MMddHHmmss'
get-childitem -path "C:\www\root\*html" -Name | sort LastWriteTime -descending | out-file -filepath "c:\temp\lsfile$timestr.txt"
select-string -path "c:\temp\lsfile$timestr.txt" -pattern "$param1" | out-file -filepath "c:\temp$param1$timestr.txt"
select-string -path "c:\temp$param1$timestr.txt" -pattern "$param2" | out-file -filepath "c:\temp$param2$timestr.txt"
$makecurrent | add-content -path "c:\temp$param2$timestr.txt"
start "c:\temp$param2$timestr.txt"

I am trying to get the PowerShell script to accept one or two parameters.

<!-- language-all: sh -->

> I know how to use @ARGS in bash. However have not seen anything comparable in powershell. I don't see any kind of array to verify the line arguments in powershell.

PowerShell's automatic $args variable is the equivalent of Bash's $@ ($*) parameter: both contain the individually passed arguments collected in an array.

The main difference is:

• $args contains arguments only (and not also a first element that contains the script name or path as invoked, as in Bash, ${@:0:1})

• Therefore, it is $args[0] that contains the first argument (compare with "${@:1:1}"), $args[1] the second (compare with "${@:2:1}"), and so on.

• $args.Count contains the number of arguments passed (the equivalent of Bash's $#).

This implies that you do not strictly need to declare parameters (via a param(...) block), if you want to accept an unconstrained, open-ended number of arguments, which would simplify your script to:

# ... no param() block needed

# ...

# Simply pass $args - containing all arguments -
# directly to Select-String's -Pattern parameter
select-string -path "c:\temp\lsfile$timestr.txt" -pattern $args | 
  out-file -filepath "c:\temp$param1$timestr.txt"

Update:

• It occurred to me later that by chaining grep calls you're looking for conjunctive logic, i.e. only lines that contain all patterns; by contrast, passing multiple patterns to a single Select-String applies disjunctive logic, i.e. it finds lines that contain any of the patterns.

• Since this post is primarily about parameter declaration and handling, I won't fix this aspect, but I can point you to a Select-StringAll helper function, available from this Gist, which provides the desired logic; you can install it directly with:

  irm https://gist.github.com/mklement0/356acffc2521fdd338ef9d6daf41ef07/raw/Select-StringAll.ps1 | iex
  

  • I can personally assure that doing so is safe, but it's always a good idea to look at the source code first).

  • If you'd rather implement the logic yourself, see Mathias R. Jessen's answer.

However, you may want to declare parameters for the following reasons:

• Use of data types:

  • Declared parameters can be declared as a specific .NET data type, such as [int] (System.Int32) or [datetime] (System.DateTime), with PowerShell's parameter binder automatically enforcing that a given argument (value) is of that type or can be converted to it.

• Use of named arguments:

  • A declared parameter can be bound (passed an argument to) in a more self-describing manner, by preceding it with the parameter's name; e.g., if you define a parameter $Pattern, an argument foo can be passed to it as -Pattern foo instead of just foo, the latter being a positional argument, whose position relative to other such arguments determines what parameter it binds to.

• Robustness:

  • You can make parameters mandatory, i.e require that an argument be passed to them; if you don't, you'll get prompted for values, but note that the UX of this prompting feature is poor - see this answer for a discussion and alternatives.

  • If you place a [CmdletBinding()] attribute above your param(...) block or use at least one parameter-specific [Parameter()] attribute, your script or function implicitly becomes an advanced one, in which case the parameter binder ensures that only arguments that bind to declared parameters can be passed.

  • Without it, arguments that cannot be bound to declared parameters are still supported, and collected in $args (which then contains only these so-called unbound arguments).

PowerShell makes it easy to declare array parameters - e.g. [string[]] $Pattern to declare an array of strings.

• By default they also require an array as their argument, meaning a single argument whose array elements are separated with , on invocation; e.g., to pass patterns foo and bar, you'd have to use
  Pattern foo, bar - note the required ,

• To get the equivalent behavior as with the automatic $args variable - i.e. to collect separate arguments in an array, you can use a [Parameter(ValueFromRemainingArguments)] attribute to decorate the target parameter, which automatically collects all positional arguments in that parameter, while allowing other parameters, if any, to be bound by name.

• You still have the option of binding such a parameter by name, in which case you again have to pass a single array as the argument, however.

• In other words: You can bind a ValueFromRemainingArguments parameter named, say, -Pattern, in one of two ways:

  • Named, with an array (note the ,):

    Some-Command -Pattern foo, bar
    

  • Positional (unnamed), with individual arguments:

    Some-Command foo bar
    

Applied to your script:

param(
  # Declare -Pattern as an array of strings that can also
  # be bound with individual, positional arguments.
  [Parameter(Mandatory, ValueFromRemainingArguments)]
  [string[]] $Pattern
)

# ...

# Simply pass $Pattern - containing all patterns -
# directly to Select-String's -Pattern parameter
select-string -path "c:\temp\lsfile$timestr.txt" -pattern $Pattern | 
  out-file -filepath "c:\temp$param1$timestr.txt"

While more complex than not declaring parameters, this form of your script has the following advantages:

• It enforces passing at least one pattern.

• It leaves you free to declare additional parameters, such as optional [switch] parameters (flags), say -CaseSensitive, which won't interfere with collecting the patterns via positional arguments.

• Through use of a [Parameter()] attribute, your script is now an advanced one, which provides automatic support for common parameters such as -Verbose or -OutVariable.

Array's are pretty simple in PowerShell - to declare a parameter as a string-array, type it [string[]]:

param(
  [string[]]$SearchTerms
)

Now you just need to repeat the string matching operation for each term supplied by the caller - we can use the -match operator against the relevant property rather than invoking Select-String:

param(
  [string[]]$SearchTerms
)

$items = Get-ChildItem -path "C:\www\root\*html" -Name |Sort-Object LastWriteTime -Descending

foreach($term in $SearchTerms){
  $items = $items |Where-Object { $_.Name -match $term }
}

return $items