On Fri, Aug 14, 2015 at 7:32 PM, Kef Schecter <furrykef@gmail.com> wrote:

PEP: XXX Title: Automatic Globbing of Filenames in argparse on Windows

For many command-line tools, it is handy to be able to specify wildcards in order to operate on more than one file at a time. On Unix-like systems, this is handled automatically by the shell. On Windows, however, the default shell does not have this behavior, nor does Microsoft's PowerShell.

Yet Windows users generally expect wildcards to work. For example, most built-in commands such as ``dir`` and ``type`` accept wildcard arguments, and have since the early days of MS-DOS.

How does this interact with the 'fileinput' module? Can you tie in with that?

How It Must Be Done Currently =============================

if platform.system() == 'Windows': filenames = [] for filename in args.files: if '*' in filename or '?' in filename or '[' in filename: filenames += glob.glob(filename) else: filenames.append(filename) args.files = filenames

Disgusting. :) Definitely needs to be buried away.

Add a keyword argument to argparse.ArgumentParser.add_argument called ``glob``. If it is true, it will automatically glob filenames using code much like the boilerplate code given earlier in `How It Must Be Done Currently`_. This argument is only meaningful when nargs is set to an appropriate value such as '+' or '*'.

+1

A possibly better behavior might be to make this argument default to True (enabling the functionality automagically without the programmer needing to be aware of it) and only expand wildcard arguments that are not provided in quotes, similar to how Unix-like shells behave. However, there appears to be no simple way to tell whether an argument was supplied in quotes or not; the strings in sys.argv already have had the quotes removed.

-1. Since Windows users aren't generally used to escaping arguments (eg compare Windows's "dir /s *.py" to Unix's "find . -name \*.py", where the latter will be backslash-protected), I would advise against glob expansion any time the program doesn't explicitly ask for it.

1. Use a version of glob.glob without the wildcard functionality that ``[`` and ``]`` provide. This type of wildcard has never been standard for wildcard arguments to MS-DOS or Windows command-line programs.

Of these, the first should adhere best to the principle of least surprise. Windows users do not expect square brackets to form wildcard expressions. If they want such functionality, they will probably already be using a shell such as bash that handles it for them.

+1. It also shouldn't do any other form of expansion (eg braces) that people wouldn't expect of a standard Windows command like dir or copy. One other difference from glob.glob() that I'd recommend: If the spec doesn't match any files, return it unchanged, as bash does. (glob.glob will return an empty list.) Otherwise, sounds good to me - make it easy to DTRT on all platforms. ChrisA

On Fri, Aug 14, 2015, at 05:32, Kef Schecter wrote:

A possibly better behavior might be to make this argument default to True (enabling the functionality automagically without the programmer needing to be aware of it) and only expand wildcard arguments that are not provided in quotes, similar to how Unix-like shells behave. However, there appears to be no simple way to tell whether an argument was supplied in quotes or not; the strings in sys.argv already have had the quotes removed.

-1, "C:\Some Directory With Spaces\*.txt" is a valid wildcard for most Windows programs.

2. Specify some kind of escaping mechanism; for example, ``\[foo\].txt`` would refer to a file that has ``[`` and ``]`` in its filename. This may not be intuitive behavior for Windows users.

Especially if you're using backslash for quoting - how do you differentiate it from backslash as a directory separator? Vim manages, but it's a bit headache-inducing to look at.

3. Keep glob.glob's standard functionality. Programs using this feature will not be able to operate on files that have square brackets in their names.

I actually think #1 is the correct way, but it's worth noting that using [[] for left bracket already works. This solution is also used in Vim (even on Windows) and MS-SQL. Right bracket needs no escaping since it's outside brackets to begin with (but you can if you want). You can even quote * and ? that way (filenames won't have them on Windows, but can on Unix).

Of these, the first should adhere best to the principle of least surprise. Windows users do not expect square brackets to form wildcard expressions. If they want such functionality, they will probably already be using a shell such as bash that handles it for them.

Speaking of least surprise... while _most_ of the quirks of Windows wildcards are extremely obscure and can probably be safely ignored for the purpose of this feature (my objection in the scandir discussion was to relying on the _real_ Windows wildcard implementation in a cross-platform function without explicitly documenting it, rather than saying it needs to be emulated), the fact that you can use *.* to match all files (including those that don't include a dot) and *. to match only files that do not include a dot is well-known. Filenames on Windows cannot actually end with a dot.

On Fri, Aug 14, 2015 at 7:32 PM, Kef Schecter <furrykef@gmail.com> wrote:

PEP: XXX Title: Automatic Globbing of Filenames in argparse on Windows

For many command-line tools, it is handy to be able to specify wildcards in order to operate on more than one file at a time. On Unix-like systems, this is handled automatically by the shell. On Windows, however, the default shell does not have this behavior, nor does Microsoft's PowerShell.

Yet Windows users generally expect wildcards to work. For example, most built-in commands such as ``dir`` and ``type`` accept wildcard arguments, and have since the early days of MS-DOS.

How does this interact with the 'fileinput' module? Can you tie in with that?

How It Must Be Done Currently =============================

if platform.system() == 'Windows': filenames = [] for filename in args.files: if '*' in filename or '?' in filename or '[' in filename: filenames += glob.glob(filename) else: filenames.append(filename) args.files = filenames

Disgusting. :) Definitely needs to be buried away.

Add a keyword argument to argparse.ArgumentParser.add_argument called ``glob``. If it is true, it will automatically glob filenames using code much like the boilerplate code given earlier in `How It Must Be Done Currently`_. This argument is only meaningful when nargs is set to an appropriate value such as '+' or '*'.

+1

A possibly better behavior might be to make this argument default to True (enabling the functionality automagically without the programmer needing to be aware of it) and only expand wildcard arguments that are not provided in quotes, similar to how Unix-like shells behave. However, there appears to be no simple way to tell whether an argument was supplied in quotes or not; the strings in sys.argv already have had the quotes removed.

-1. Since Windows users aren't generally used to escaping arguments (eg compare Windows's "dir /s *.py" to Unix's "find . -name \*.py", where the latter will be backslash-protected), I would advise against glob expansion any time the program doesn't explicitly ask for it.

1. Use a version of glob.glob without the wildcard functionality that ``[`` and ``]`` provide. This type of wildcard has never been standard for wildcard arguments to MS-DOS or Windows command-line programs.

Of these, the first should adhere best to the principle of least surprise. Windows users do not expect square brackets to form wildcard expressions. If they want such functionality, they will probably already be using a shell such as bash that handles it for them.

+1. It also shouldn't do any other form of expansion (eg braces) that people wouldn't expect of a standard Windows command like dir or copy. One other difference from glob.glob() that I'd recommend: If the spec doesn't match any files, return it unchanged, as bash does. (glob.glob will return an empty list.) Otherwise, sounds good to me - make it easy to DTRT on all platforms. ChrisA

On Fri, Aug 14, 2015, at 05:32, Kef Schecter wrote:

A possibly better behavior might be to make this argument default to True (enabling the functionality automagically without the programmer needing to be aware of it) and only expand wildcard arguments that are not provided in quotes, similar to how Unix-like shells behave. However, there appears to be no simple way to tell whether an argument was supplied in quotes or not; the strings in sys.argv already have had the quotes removed.

-1, "C:\Some Directory With Spaces\*.txt" is a valid wildcard for most Windows programs.

2. Specify some kind of escaping mechanism; for example, ``\[foo\].txt`` would refer to a file that has ``[`` and ``]`` in its filename. This may not be intuitive behavior for Windows users.

Especially if you're using backslash for quoting - how do you differentiate it from backslash as a directory separator? Vim manages, but it's a bit headache-inducing to look at.

3. Keep glob.glob's standard functionality. Programs using this feature will not be able to operate on files that have square brackets in their names.

I actually think #1 is the correct way, but it's worth noting that using [[] for left bracket already works. This solution is also used in Vim (even on Windows) and MS-SQL. Right bracket needs no escaping since it's outside brackets to begin with (but you can if you want). You can even quote * and ? that way (filenames won't have them on Windows, but can on Unix).

Of these, the first should adhere best to the principle of least surprise. Windows users do not expect square brackets to form wildcard expressions. If they want such functionality, they will probably already be using a shell such as bash that handles it for them.

Speaking of least surprise... while _most_ of the quirks of Windows wildcards are extremely obscure and can probably be safely ignored for the purpose of this feature (my objection in the scandir discussion was to relying on the _real_ Windows wildcard implementation in a cross-platform function without explicitly documenting it, rather than saying it needs to be emulated), the fact that you can use *.* to match all files (including those that don't include a dot) and *. to match only files that do not include a dot is well-known. Filenames on Windows cannot actually end with a dot.