none
Get-ChildItem with Variable Filter RRS feed

  • Question

  • It really shouldn't be this hard. Really it shouldn't. I've read the examples but I'm running short on ideas to resolve this.

    Why won't this WORK!

    Function Get_ToolData($path,$filter){
    $files = Get-ChildItem $path -Filter $filter
    $files
    }
    
    Get_ToolData("\\server\path","*.csv")


    David Jenkins


    Monday, September 14, 2015 2:28 PM

Answers

  • Do not use parentheses and commas when calling a PowerShell function.

    The way you are calling your function, you are passing an array to your function's $path parameter.

    Your function call should be:


    Get_ToolData "\\server\path" "*.csv"


    -- Bill Stewart [Bill_Stewart]

    Monday, September 14, 2015 2:32 PM
    Moderator

All replies

  • Do not use parentheses and commas when calling a PowerShell function.

    The way you are calling your function, you are passing an array to your function's $path parameter.

    Your function call should be:


    Get_ToolData "\\server\path" "*.csv"


    -- Bill Stewart [Bill_Stewart]

    Monday, September 14, 2015 2:32 PM
    Moderator
  • That was it. 

    I got my JavaScript mixed with my PowerShell.

    Thank you!


    David Jenkins

    Monday, September 14, 2015 2:34 PM
  • It is inconsistent in PowerShell that you can code the formal arguments to a function with parentheses and commas, yet you cannot call the function using that pattern.   It is just a PowerShell thing that has to be learned and reinforced before it becomes commonplace to the user of PowertShell.   The confusing thing is that
     ("\\server\path","*.csv")
    is interpreted as a value that is mapped only to $path and $filter is allowed to not have a value, with no runtime diagnostics to warn about that seldom desired pattern when a function argument is expected to be left undefined at times.   Someday, I'd like to see a "lint" like level of diagnostics built into PowerShell.     lint was the name originally given to a program that flagged suspicious and non-portable constructs (likely to be bugs) in C language source code.

    Monday, September 14, 2015 4:13 PM
  • This is because, in PowerShell, the param statement can be included in the function header:


    function name(param1, param2[, ...]) {
    

    The above is equivalent to:


    function name {
      param(param1, param2[, ...])
    

    The first syntax is a concession to other languages that declare a formal parameter list with the function name. Agreed that this tends to cause confusion because it is not correct, semantically, to call a function using this syntax. For this reason I recommend declaring functions using the second syntax. The second syntax also reinforces the fact that scripts and functions are essentially identical.


    -- Bill Stewart [Bill_Stewart]

    Monday, September 14, 2015 4:20 PM
    Moderator
  • This is because, in PowerShell, the param statement can be included in the function header:


    function name(param1, param2[, ...]) {
    

    The above is equivalent to:


    function name {
      param(param1, param2[, ...])
    

    The first syntax is a concession to other languages that declare a formal parameter list with the function name. Agreed that this tends to cause confusion because it is not correct, semantically, to call a function using this syntax. For this reason I recommend declaring functions using the second syntax. The second syntax also reinforces the fact that scripts and functions are essentially identical.


    -- Bill Stewart [Bill_Stewart]

    I thought about that, but look at the param(,,,) pattern and you see the same use of parenthesis and commas as the pattern I wrote about.
    Monday, September 14, 2015 6:34 PM
  • I thought about that, but look at the param(,,,) pattern and you see the same use of parenthesis and commas as the pattern I wrote about.

    That is true, but param is a single statement with an array of declared parameters. That's not the same as passing parameters to a script or function. Understandably, this is still a bit confusing, but in my opinion it is slightly less confusing than declaring the parameters directly after the function name.


    -- Bill Stewart [Bill_Stewart]

    Monday, September 14, 2015 6:50 PM
    Moderator
  • I liked using PARAM instead of (item1,item2) method.  This way I can user the parameters in any order.  It's just easier.

    Thanks for the thoughts on this.  Much appreciated.


    David Jenkins

    Monday, September 14, 2015 6:52 PM
  • The parameter order stays the same no matter whether you declare them using the param statement or directly after the function name.

    In either case, though, you can call the function using parameters in whatever order you want if you include the parameter names.

    This is documented in the help topics about_Parameters and about_Command_Syntax.


    -- Bill Stewart [Bill_Stewart]

    Monday, September 14, 2015 7:01 PM
    Moderator
  • The parameter order stays the same no matter whether you declare them using the param statement or directly after the function name.

    In either case, though, you can call the function using parameters in whatever order you want if you include the parameter names.

    This is documented in the help topics about_Parameters and about_Command_Syntax.


    -- Bill Stewart [Bill_Stewart]

    All true.    

    Thinking about it some more, declaring ParameterSets is one thing that can only be done via the param() construction.    That is an "advanced function" topic.
    https://technet.microsoft.com/en-us/library/hh847743.aspx
    Monday, September 14, 2015 7:35 PM