python 2.7.12 on Linux behaving differently than on Windows

[Chris Angelico]

On Wed, Dec 7, 2016 at 7:30 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> If you accidentally say "del *" on Windows, say, when you meant "z*" for
> example, and Windows deletes all the files in the current directory, do you say
> to yourself...?
>
>    "Thank the deities that * was expanded by the del command rather
>    than the shell! Imagine how awful it would have been if the shell
>    did the expansion!"

There is one special case: if you use "*.*" on Windows, the del
command will prompt. However, there are plenty of other examples where
this special case doesn't apply.

> 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.
>
>
>
> 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?

Not a Windows expert, but I happen to know this one; and it's another
special case. If you provide only one argument (and a glob does count
as a single argument), copy assumes you mean "to the current
directory" - ie an implicit "." as a second argument.

So you've landed on two special cases in Windows commands that take
advantage of the fact that the app has to expand globs. They give a
marginally better result at the cost of consistency. I believe the Zen
of Python has something to say about special cases; while there
definitely are times when that line is wrong, there are a lot of times
when it's right, and forfeiting consistency is usually too high a cost
for the benefit gained.

>> (2) There have been 40 years of it working this way and there have never
>> been any problems. (That is, 40 years of writing programs with
>> stultified command line interfaces to make sure that is always the case.
>> [As for 'problems' such as the 'cp *.c' one, that's a feature!]
>
> Don't be absurd.
>
> Any Unix sys admin can tell you stories of accidentally globbing too much and
> screwing something up. And any Windows sys admin can tell you the same stories,
> even though globbing is handled by the individual programs rather than the
> shell.

And a lot of the over-globbing examples depend on very specific
situations. With "cp *.c" and no destination, Unix cp will silently do
the wrong thing ONLY if there are exactly two files matching that
glob, or if everything matching that glob is a file except the last,
which is a directory. (With most globs, that's unlikely.) With Windows
"copy *.c", it gives an obscure error message ONLY because you didn't
have a path on the glob; if you say "copy source\*.c", it'll silently
do the wrong thing.

Let's face it. You should be using git anyway. Then you have a
protection *no matter what* you mess up - just check out any files you
messed up. Tada!

> (At least, any Windows sys admin who uses the command line, or writes batch
> files. I dare say those who use nothing but GUI tools have their own,
> different, horror stories.)

Oh, absolutely. How about a Windows domain controller that BSODed
multiple times just trying to pull up the config program?

http://thedailywtf.com/articles/the-infrastructure

Part of that WTF is that the domain controller had no remote access.
But what's the cost (in server load) of a GUI-based remote admin
facility? Decidedly non-zero. How about good ol' SSH? So light that
I've been able to use it to remote in to a computer that had gotten
itself into some sort of infinite loop, and find out what was going
wrong. And fix it without rebooting, too. If your solution to
everything is "bah, just reboot", then you don't have a solution.

> But Unix systems are the end product of 40 years of directed evolution by
> thousands of sys admins who have designed the shells to work the way they want.
>
> 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
> 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.

Exactly. Back in the 1990s, we had the beginnings of Windows NT, which
was designed for servers. It had (if I recall correctly) no concept of
file/directory permissions, little or no notion of process privilege,
and definitely no way to restrict one process to X amount of memory
and Y amount of processing. Since then, Windows has progressively
added features that Unix has had for decades, because those features
are critical. Those who don't understand Unix are forced to reinvent
it, piece by piece, badly, and then finally rip it out and start
over...

ChrisA