Ubuntu on Windows

It's a bit more than UNIXy, (the proper term is Unix-like), it literally is UNIX. It meets the UNIX 03 specifications.

Also, the motivations for these move predate the rise in popularity of Apple. For years, one of the biggest complaints about Windows was the lack of a good command line interface. There was the legacy CMD.EXE, which provided support for DOS commands and batch files, and PowerShell, which people either love or hate. The reality, however, is that overwhelmingly, the combination of bash/zsh and coreutils, binutils, util-linux, etc. won out a long time ago. Most schools use a flavor of Linux (maybe Solaris) for teaching Computer Science (and related disciplines), so many people who have formal training are used to those. Those people tend to teach other people to use them, etc.

Some people bemoan the fact that the CLI never evolved past its UNIX origins, but the reality is these tools work just fine. There's never been a reason to evolve them.

http://www.opengroup.org/openbrand/register/brand3612.htm

On the contrary; there have been many valid reasons to evolve them, but backward compatibility was deemed more important.

Example #1: it is possible to write a sh/csh/bash/?sh script that handles file names with spaces, slashes, quotes, question marks, etc, but one would hope that would be made a bit easier, almost half a century later.

Example #2: the hack that is xargs for handling large numbers of arguments. To write a truly robust script that handles directories with an arbitrary number of files, one should run a pipeline using find and xargs, instructing xargs to do the actual work (and you cannot even use find and xargs with their default settings; you need -print0 and -0 flags to handle file names with spaces, etc)

If programs received arguments unexpanded, and the system had a library for expanding arguments, many use cases would become a lot simpler, and scripts could become more robust.

And yes, that could have been evolved. Headers of executables could easily contain a bit indicating "I'll handle wild-card expansion myself".

Example #3: man pages, IMO, should be stored in a special section inside binaries. That ensures that the man page you read is the man page for the executable you have.

Example #4: http://unix.stackexchange.com/questions/24182/how-to-get-the... shows that things _have_ evolved. Reading and parsing /etc/mtab isn't a reliable way to find all mount points, just as reading /etc/passwd file isn't the way to find password hashes anymore, ar has long been upgraded to support file names longer than 14 characters, and zip knows more file attributes than it used to.

2) Now paralell is better

3) Never. You should be able to check the man pages even if you can't access the binaries.

2. GNU Parallel is actually my choice for this, because xargs has a few known issues. Parallel gets the most right, and I used it a lot in my research to run scripts on lots of data.

3. Hell no. Distributions do this job perfectly fine, and you should be able to read the man pages without having read permissions for the binary (since in UNIX you can have 111 as permissions on a binary).

No, it actually won't. There are so many tricks and caveats with shell expansions, wildcard handling etc, that regularly old unix hats I know get it wrong (and I've started on Sun OS, probably before half of HN was born).

This is like saying "pointers are nothing, you can learn them in a day" ignoring the obvious fact that the interplay with pointers in a large app is something entirely different than merely understanding indirection, and than even the best kernel/driver/crypto/etc programmers still get pointer related bugs after decades of writing C.

>3. Hell no. Distributions do this job perfectly fine, and you should be able to read the man pages without having read permissions for the binary (since in UNIX you can have 111 as permissions on a binary).

Actually, no, they don't do it at all. One can have 3-4 different versions of a userland program, and never know (unless they explicitly check versions) for which the man page is.

This seems like a prime example of the "Anything I am good at using is objectively easy to use" fallacy that's common to programmers.

It'll get better through rewrites, new tools, different infrastructures etc long before it gets better through iteration on the same tools. That's OK though :)

Err. As a Mac user from when system 7 was fancy looking, and who learned some basic bash in order to do useful stuff like use curl, grep, cat, ls > .txt, rm's based on partial name matches, etc. my only response is "How about we talk about it over breakfast, lunch, and dinner?"

Bash is simultaneously graceful and nimble, yet clumsy. While it's certainly appropriate to worry that any reduction of the clumsy side would have a net negative effect, to not see, or not ack the many issues just continues to deny its utility to non-expert users.