python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 07/12/2016 08:30, Steven D'Aprano wrote:
> On Wednesday 07 December 2016 03:41, BartC wrote:
>
>> On 06/12/2016 15:44, Michael Torrie wrote:
>>> On 12/06/2016 04:43 AM, BartC wrote:
>>
>>> Yes shell expansion has it's gotchas.  But those can all be learned,
>>
>> Yes, learn to avoid wildcards in command parameters at all costs. But we
>> both know that is not satisfactory.
>
> Now you're being ridiculous. Can't you at least debate this sensibly?
>
> There are Windows programs which understand globs, like dir. Do you honestly
> expect us to believe that it is okay to use "dir a*" on Windows because dir
> itself expands the glob, but not okay to use "dir a*" on Linux because the
> shell has expanded the glob before dir sees it?

You don't get it.

The problem is the program not seeing the original unexpanded parameters 
that it wants, with extra information that is lost when indiscriminately 
expanded.

> Tell me Bart, what's the difference between these?
>
>     # Linux
>     rm *
>
> and
>
>     # Windows
>     del *

It asks 'Are your sure?'. But that is beside the point. And commands 
such as 'del' /are/ crude.

But if a program existed that took N filename parameters with the 
purpose of deleting each of them, then it can't tell if they were typed 
in individually (so indicating a stronger intent), or whether a finger 
slipped on a single filename and a "*" was added, in which case it could 
choose to ask for confirmation *if* it saw that this is a wildcard).

'Globbing' (if that means auto expansion) is taking away choice.

> I see that the Windows version of copy avoids this *by accident*:

> C:\Documents and Settings\Steve>copy a*
> a1
> The file cannot be copied onto itself.
>         0 file(s) copied.

No, even if it did copy the file, it would be harmless. 'copy' chose to 
make the second parameter option, and to make it default to "."

> Instead of accidentally copying a1 over a2, it accidentally tries to copy a1
> over a1, and fails. At least, that's what it looks like to me. Any Windows
> expert like to chime in?

a1 would be copied to a1, a2 to a2. That's how it has to work otherwise 
all files would be renamed when copied elsewhere!

>
> The bottom line is, it doesn't matter where the wildcards are expanded. Whether
> the shell does it, or the application itself, they're dangerous by their very
> nature.

They can be dangerous with certain commands and programs that accept 
wildcards (which aren't many actually; I don't think any of my programs do).

With automatic expansion, then EVERY program can become dangerous. Can 
no one else see this?

> I get that its not the way that you like, but fortunately for you, they
> provided not one, but TWO easy ways to get the results you want:
>
> - escaping the metacharacters you want to be left untouched;
>
> - disabling globbing (for either a single command, a session, or permanently).

If the default is to have it on, then that's not satisfactory.

> If *your* design was paramount, it would be up to each and every application to
> choose whether or not to support globbing and environment variable expansion,
> and hard luck if the application I needed to use didn't understand the globs I
> wanted.

How many programs take parameters that specify multiple files and work 
on them together? As I said, I think hardly any of mine do.

>> The fact that you also lose format information (is it three parameters,
>> or one parameter transformed into three) is an extra bonus.
>
> Here's a two-line Python program to prove what nonsense that is.
>
> steve at runes:~$ cat argv.py
> import sys
> print( sys.argv )
>
>
> And in use:
>
> steve at runes:~$ python argv.py a\* z\*
> ['argv.py', 'a*', 'z*']

But in real use it will be:

  python argv.py a* z*

It took me a while to recognise the significance of the "\". In Windows 
that's a path separator.

Yes, there are any number of ways that *you* or *I* can get AROUND the 
problem. But my background in the past has been with users (and talking 
through bunches of console commands on the phone).

But the problem is still there.

> And it looks like Windows is ever-so-slowly converging on the same, or at least
> similar, sets of conventions: by copying Unix globbing metacharacters in the

(I'm sure I used these in the 1970s. Or was DEC copying Unix?)

> first place, then by adding them to the C library to make it easy for
> applications to do their own globbing, then by moving to PowerShell, and the
> latest step is Microsoft's partnership with Canonical (the company behind
> Ubuntu Linux) to bring bash to Windows.

Most open source software seems to be written in C and seems to require 
executing a 20,000 or 30,000-line bash 'configure' script, itself 
dependent on a dozen Unix utilities, before it's possible to build it. 
Even if the resulting product is cross-platform.

So that's not surprising, if everyone is obliged to install Msys or 
Cygwin anyway. (Apart from me, as I refuse to do anything like that. If 
a program is in C, then I should need only a C compiler. Any software I 
make available takes exactly that approach.)

-- 
Bartc