I think if you try to submit a bug report for a module, saying that it works wrong when you redefine several perl special variables, nobody will agree to fix that.

But why? It's not wrong to assign a value to those special variables. That's what they are for. If you don't ever assign values to them, there's no reason they'd need to exist at all.

So, why would somebody reject such a bug report? Maybe because it's unsual that it's done in code that isn't a oneliner.

But bug with filename '0' is different case. It's a bug, absolutely.

But one can argue that using 0 as a file name is also unusual.

What do you think about modules that can't handle file names that contain quotes? Or a newline? Is that also a bug, absolutely? What about not handling non-ASCII file names (for which there seems to be no cross-platform way of handling them corectly)?

You draw a line and say "not handling non-default $, is not a bug", but you say "not handling 0 filenames is a bug". Based on what criteria do you draw that line? And where do you draw it?

For the record, I too would consider not handling a filename of 0 a bug, but I lack your perspective on which corner cases need to be handled, and which are OK to ignore.

Hi moritz,

Well said. I share your opinion. To your question

...you say "not handling 0 filenames is a bug". Based on what criteria do you draw that line?

I want to give a nucleus for a hopefully intersting discussion. Can it be that user's or programmer's expectation is the driving criteria?

To stick at the filename example (which shouldn't be in the focus of my thread), years ago nobody expected that filenames containing non-ascii characters would work, but nowadays I'm pretty sure that users expect to be able to write e.g. German umlauts in their filenames.

Are common expectations (yes, yes, it's very vague) a kind of implicit, unwritten requirement? :-)

McA

There is no strict criteria.

If you don't ever assign values to them, there's no reason they'd need to exist at all.

if you use it - localize it, and don't call other modules inside scope.

File::Find uses user's $; and it won't be fixed https://rt.perl.org/rt3/Public/Bug/Display.html?id=116350#txn-1183176

Sad there is not Perl documentation saying in which case those variables should be localized (or there is?).

What do you think about modules that can't handle file names that contain quotes?

bug.

Or a newline?

small bug (user is just waiting for troubles with those filenames)

What about not handling non-ASCII file names

means module does not support Unicode or specific platform (some perl core modules doest not support unicode - this is the criteria)

for which there seems to be no cross-platform way of handling them corectly

It depends on what's "handling". I think there is way to just open files, crossplatform (except non Unicode platforms). Anyway, looks like a bug (if undocumented) or missing feature (if listed as known bugs). btw File::Find has open bugs for it.

Based on what criteria do you draw that line?

The big difference, that programmer control perl variables, but does not control user's filenames. Also it depends on what program do. If it just open a one user supplied file - it's one case. If it searches files on disk and opens each of them - even user cannot control filenames, so it should handle (or at least catch an error) any valid filename.