[PS] Positionality of wildcards? Bug?

Discussion in 'Scripting' started by Andrew Watt [MVP], May 15, 2006.

  1. In PowerShell wildcards seem to be implicitly positional.

    Try this
    PS C:\Documents and Settings\Andrew Watt> "pam", "amateur", "sam" |
    where-object {$_.ToString() -match "[a-m].*"}
    pam
    amateur
    sam
    PS C:\Documents and Settings\Andrew Watt> "pam", "amateur", "sam" |
    where-object {$_.ToString() -like "[a-m]*"}
    amateur

    The wildcard behaves like the regular expression "^[a-m].*".

    In that respect it differs significantly from wildcard behaviour in
    Word and Excel.

    Try Ctrl+F in Word (with wilcards turned on) in a document with pam,
    amateur and sam in it.

    The results (for the same wilcard pattern) are VERY different. Many
    matches that Word / Excel wildcards find are non-matches in PowerShell
    - I assume because of the implicit positionality.

    1. The implicit positionality is not documented.

    2. Is the implicit positionality the correct behaviour for wildcards?

    Thoughts?

    Thanks

    Andrew Watt MVP
     
    Andrew Watt [MVP], May 15, 2006
    #1
    1. Advertisements

  2. I think the term you're looking for is anchored. If so, then yes, wildcard
    expressions are anchored. (Regular expressions are not by default.) So
    dir f*.txt
    finds all of the .txt files that begin with the letter f. The corresponding
    regex is
    ^f.*\.txt$
    This is intended and matches the behaviour of cmd.exe as well as sh, bash,
    ksh, the standard POSIX shell, and so on. (Out of curiosity, does anyone
    know of a shell where this is not case?)

    -bruce
     
    Bruce Payette [MSFT], May 16, 2006
    #2
    1. Advertisements

  3. Thanks, Bruce.

    Can you comment on the differences in what is matched between
    PowerShell wildcards and Word or Excel wildcards? The latter wildcards
    are not anchored.

    I think the differences in behaviour are worth discussing because
    wildcards in PowerShell won't simply be used to interpret a command
    line, they will also be used inside text documents.

    e.g.

    get-content Something.txt | where-object {$_ -like
    "a*somewildcardpattern"}

    the "anchoredness" is going to affect what is matched. And what is
    going to be matched will be different from matches when the "same"
    wildcards are used on text in Word, for example.

    I guess that, for legacy/compatibility purposes PowerShell will go
    with command line wildcard semantics but when the reach of the
    wildcards is being extended into other territory (text documents) I
    think the existing semantics in that scenario also need to be
    carefully considered.

    75842 on Connect. Connect discarded the original due to a timeout.
    <sigh/>. So I rewrote it more briefly.

    Andrew Watt MVP

     
    Andrew Watt [MVP], May 16, 2006
    #3
  4. I agree with the point you make here, although I think the current behavior
    is "most correct". Here's my thinking about it since I've worried about this
    before.

    + Consistency
    There are MANY inconsistencies in wildcard matching in various software
    packages on Windows; the implementations have usually been very superficial
    and incomplete. Generally, I favor a consistent standard for the matching so
    that it can be used in new contexts without needing domain-specific
    knowledge.

    + More Control
    Implicit anchoring of wildcards gives better control over matching. If you
    want to find a pattern containing "foo" you can do "*foo*" if you have
    implicit anchoring (IA) and just "foo*" if you don't have IA. If you want to
    find a pattern _beginning_ with "foo", however, you can only do it with
    implicit anchoring.
     
    Alex K. Angelopoulos [MVP], May 17, 2006
    #4
  5. Yes, wildcards on Windows are a mess.

    Since version 1 of PowerShell is a potential watershed I thought it
    was worth pushing hard to see if we could get somewhere towards
    clearing up the mess but the competing wildcard "messes" mean that any
    "consistency" would upset somebody.

    Given the history and command line emphasis of PowerShell and the need
    to make PS seem as easy as CMD.exe (and similar to it and Unix shells)
    I think the implicit anchoring is the "least bad" / "best" way to go
    for this product. Whether it's the "right" way to go is another
    question. But I can accept that it's a sensible choice in context.

    Andrew Watt MVP
     
    Andrew Watt [MVP], May 17, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.