Ubuntu on Windows

[1] http://www.slideshare.net/bcantrill/illumos-lx

[2] http://us-east.manta.joyent.com/patrick.mooney/public/talks/...

[3] https://news.ycombinator.com/item?id=11392119

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.