[elektronjunge]

Having implicit shared state dependent on the requested type is certainly not consistent. To a reasonably experienced perl programmer one would expect the following:

    @globs = glob("*") # all matches
    $glob1 = glob("*") # the first match of "*"
    $glob2 = glob("*.c") # the first match of "*.c"

[kbenson]

I agree that's the behavior you would want for that example. That is almost the behavior you get when use use File::Glob's bsd_glob function. For some reason it instead appears to return the last alphanumerically sorted match instead of the first. I've submitted a bug about that as well as the general lack of documentation on the true behavior of the CORE::glob() function, as outlined in my other comment.

[zzzcpan]

I disagree. You would expect what it says in documentation, and it says it should iterate over the list.

If you want the first element of the list, you should say exactly that to the compiler, i.e. force list context and take the first element:

    ($file1) = glob("*");

[kbenson]

> I disagree

I assume because you misread the example given there. If you note that $glob1 and $glob2 come from what should be different lists (all files in working dir and all files ending in .c in the working dir), then $glob1 and $glob2 should contain the first item each of their respective lists. That's exactly what the documentation says should happen.

> You would expect what it says in documentation, and it says it should iterate over the list.

Unfortunately it doesn't even do what it says in the documentation consistently. I have another comment here that outlines that fairly thoroughly. The behavior is very weird and specific to glob, and is not documented accurately.

[zzzcpan]

I guess I misread the example, sorry. I thought we were talking in the context of inconsistent behavior of Perl as a language and therefore its syntax, but not in the context of an undefined behavior of glob().

[kbenson]

We are and we aren't. elektronjunge chose an example that definitely is inconsistent, but I'm not sure that it's really indicative of Perl in general. IMHO, It's a fairly specific kind o broken, where we can't really fix the behavior because of backwards compatibility, but the documentation is just plain inadequate in this case as well.

[prakashk]

It does return the values as expected. See my other reply: https://news.ycombinator.com/item?id=8730798

[kbenson]

Actually, it doesn't, and it's complicated. See my rather long-winded reply here: https://news.ycombinator.com/item?id=8730925

[zzzcpan]

http://perldoc.perl.org/perldata.html#Context