The first case is different from the others. Using warnings helps there:

$ perl -wle 'print <x>'
Name "main::x" used only once: possible typo at -e line 1.
readline() on unopened filehandle x at -e line 1.
[download]

Using B::Deparse on the other three tells us that they use the same program structure:

$ perl -MO=Deparse -le 'print <x*>'
BEGIN { $/ = "\n"; $\ = "\n"; }
use File::Glob ();
print glob('x*');
-e syntax OK
[download]

Using that snippet for your first case as well gives:

$ perl -MFile::Glob -wle 'print glob "x"'
x
[download]

So glob treats the two first cases differently. The documentation says that it implements csh semantics. I guess that's why.

It comes from shell glob expansion behaviour. That is what the shell does to the command line before it passes it on to the program. So if you have just listed some arguments, it will pass along those arguments. If you have listed some arguments with wildcards, it will expand those wildcards into a file list. And so on.

It even has some features to make it easy to write things like this:

cp some-long-filename{,.bak}
[download]

That said, if you don't come to Perl with this background, Perl's glob behaviour is very surprising. And can lead to lots of subtle bugs. Plus when I'm in defensive mode I don't trust programs that will do different (and surprising!) things depending on whether the file I'm looking for is there.

So it's a feature. But surprises and can lead to bugs.

Which is why in "real code" I tend to use opendir and readdir directly (possibly hidden behind a function).

PS If you want behaviour closer to Ruby's, just grep for files:

perl -e 'print grep -f, <x.>'
[download]

Ah thanks for the clearing up. I do use Unix shell regularly for some years, but bash and never csh. So apparently they differ in wildcard expansion when it comes to non-matching wildcard containing ? or *.