If you're thinking "but... it's all so obvious. What is this guy talking about", ask yourself how long ago you first typed a shell command. Can you even remember how hard it was to learn? For me it was something like 15 years and I actually can remember because it made such an impression on me how terrible a system it was. (That and X86Config if you remember that insanity.)
Even though it was awful to learn, it feels totally easy and 'intuitive' to me now. But that's just because I use it so much. It's not intuitive. Don't fall into the old curmudgeon trap of thinking the thing that you find trivial through experience is actually good.
/rant
No you don't; whether ls is a builtin is mostly irrelevant, but
ls *1*.png
does exactly what you (I assume) are saying, dir *1*.png
which AFAIK is a new extension introduced with WinNT's command processor, since the old algorithm...https://blogs.msdn.microsoft.com/oldnewthing/20071217-00/?p=...
...would effectively produce a pattern matching all files ending in '.png'.
ls doesn't do glob matching. ls '*' would try to fstatat (FreeBSD) that character.
EDIT: formatting
It's very common to think of the first thing you learnt as more intuitive. Learning the second thing you have baggage and expectations of how something is supposed to work.
From what I recall, it was easy. Other than a few small differences ("mkdir" instead of "md", needs a space between the "cd" and the "..", and so on), it was similar to what I used every day. The rest I learned gradually, by reading shell scripts written by other people, and the man and info pages.
As for XF86Config, I always used the XF86Config generators which came with the distributions, so it was never much of a problem for me.
I can remember when I first learned bash/sh and Unix systems in general (by reading a book) and it was not really hard. However, I saw your sentiment a lot among the students I used to teach, and my response has always been "you're approaching it the wrong way." Bash, PowerShell, etc. are effectively programming languages, and my advice for learning programming languages applies: it's a language.
To elucidate, programming languages have their own vocabulary and rules just like a human language (and often, the rules are far more consistent and the vocabulary smaller) --- to ask questions like "Why not `list`?" is like asking "Why is the plural of sheep, sheep? Why is it called a mouton in French? Why not sheepe?"
Of course, you can ask such etymological questions when learning about programming languages and use them to help you, because they will have far more logical answers than the same questions about human languages; but in general, learning a language as a language is the best way to progress.
In fact I'd say super-verbose and somewhat convoluted languages like PowerShell (and C#, which I don't fancy much either --- nor its Java-ish ancestry, for that matter) may only appear to be more intuitive at first, but are actually hiding some quite nonintuitive complexity. The verboseness may make it easier to get started, but becomes a hindrance thereafter.
/rant
Some historical syntax ancestry aside, state-of-the-art C# is too classy and elegant to be in the same sentence with Java.
But unlike normal languages, software languages are designed. So asking why questions makes a lot more sense.
I wanted to do floating point math. The recommended answer is to pipe your data into a better programming language. You can't even do math in bash. On another occasion I wanted to make a simple program that opens a random file. The recommended answer breaks in the simple case where files have spaces in them. The correct answer I found is this horrible mess of weird characters and it's completely incomprehensible. The best answer someone submitted was just to call one line of python from bash...
And why is it so wrong for the shell to be a decent programming language? It's not impossible. It doesn't need to make anything harder or more complicated. And it adds a ton of functionality. There are tons of people programming in Bash and powershell anyway.
You shouldn't, certainly, but, as to 'can't', I think that `expr` (or, as I just learned from ABS, `$(( ))`) covers a lot of basic uses: http://www.tldp.org/LDP/abs/html/arithexp.html .
Someone who tries to learn Chinese may have the same thought after having been exposed to nothing but English. The keyword is "language".
The quoting rules in bash/sh are not difficult to memorise, and definitely a must-learn.
I wanted to do floating point math.
Maths is not a strong point of shell languages because they were designed more for string manipulation and gluing other programs together. Try doing pipelines and redirection in a "real programming language", for a contrasting example.
"The right tool for the job".
mv and ls are not shell commands, they are programs. They existed long before bash and were developed at a time of 110 baud teletype connections when short, highly abbreviated command names were worth the inconvenience.
If you don't like them you're free to alias "rename" to "mv" and "list" to "ls"
"How do you end this block? Maybe... I type 'end'? Nope! You write the opening statement backwards! Ha ha get it? Backwards lol!"
done?
Also, there's a story behind all these commands, their naming, the symbols, reasons for the brevity. But I've never not found Unix intuitive, even before I was aware of the reasoning behind everything. That said, Unix is definitely an environment for the more savvy. But what's intuitive for me is not necessarily intuitive for someone less savvy.
It redirects standard error to standard out? That's what it does in powershell anyway. Frex, I got this line in my $PROFILE:
$p2 = & $env:Python_2/python.exe --version 2>&1
To get the current Python 2 version on my machine. I'm not really sure what it's an alias for, but I like having the shortcut of the more concise syntax.The real problem is that, for some reason, python.exe --version outputs to standard _error_. That, I don't really get. I'm sure there's a good reason for it but it's not obvious and that's what's making the "2>&1" at the end hard to figure out.