A little more information gleaned by experiment, as I stil have yet to find any documentation on this. MS or otherwise. YAROSF! (Yet Another Redmond-Only Secret Feature!)

After a some more thunking and chundering, I discovered that both '<' and '>' are "special" when used in filenames passed to the Find(First|Next)File() APIs.

• '<' is similar to '*', but its 'wildness' is bounded by '.'s.

  Given the files

  P:\test\xxx>dir /b
  test.test.X
  test.test.XX
  test.test.XXX
  test.test.XXXX
  test.test.XXXXX
  test.X
  test.XX
  test.XXX
  test.XXXX
  test.XXXXX
  [download]

  'test.*" will match them all but 'test.<' will only match

  test.X
  test.XX
  test.XXX
  test.XXXX
  test.XXXXX
  [download]

  it would require 'test.<.<' t match the rest.

  This is somewhat analogous to the behaviour of '.' in a regex matching "\n" (or not) depending upon the precesence or absence of the /s modifier.

• '>' is similar in behaviour to '?'. At first I could find no difference as the wildness of '?' is already limited to not matching '.'s.

  Given the set of files above,

  • 'test?' and 'test>' will match none of them,
  • 'test.?' and 'test.>' will find 'test.x'
  • 'test*.?' and 'test*.>' will find 'test.x' and test.test.x'
  • 'test>.?' and 'test>.>' will only find 'test.x'

There is a difference but in typical fashion, it is incredibly hard to define. It only seems to come into play when there are two (or more?) '.'s in the wildcard spec. This is a far from comprehensive expose of the possibilities, but unless someone else can find some rhythm or reason to the pattern matching possibilities of this, its going to be like the CLI quoting rules, too damn complex to work out, never mind to try and remember and apply usefully.

In terms of bypassing this 'feature', I think I would opt for something like

$filespec =~ s/(^[<>+|\s]+) | ([<>+|\s]+$)//;
[download]

Which I think will deal with any two-arg open adornments without changing the native behaviour or unnecessarily limiting the range of ligitimate filespecs you handle.

It strikes me that it should be left to the calling code to decide if the values they pass in to you should be untainted or not.