>There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point.

Well, if by trivial you mean "totally effortless and thoughtless" then not. But I don't think that's the correct mental mode to create CLI interfaces either.

>But daemons are not command line tools. Command line is just a way to start them under unices. Under Windows it's a totally separate type of programs ("Windows services").

Command line is any headless program. And you can start Windows servers from the command line too.

>Even aside from that, daemons are not normally called for one-off tasks, but to provide services. This means you already need a communication channel for such a daemon.

That's narrow thinking.

First, e.g. "grep" also provides a service of returning matching results. Whether it does it once-of or as a deamon (one could easily imagine a grep deamon, not unlike Solr or Spotlight) is irrelevant with respect to its scriptability.

It's only because we don't plan for it, that we have this artificial restrictions -- "that's a deamon, you can't script it like that".

Besides, regarding "This means you already need a communication channel for such a daemon.", that's a different channel than the scriptable one, because the latter would include stats, configuration etc.

A web server has a channel to do "GET / HTTP/1.0", but that's not the same as a chanel allowing you to e.g. "print current connected IPs", "reload X configuration file", etc.

>Current working directory? ROTFL. The whole point of GUI is to hide this concept, and you tell me one can learn it from GUI?

No, the whole point of the GUI is to give a graphic representation of those concepts, not to hide them. It hides absolutely nothing (except things that don't make sense in a GUI, like the CLI hides stuff that don't make sense in a terminal, eg. the graphical representation of an jpg file, which a GUI can immediately show in its listing).

In fact one can trivially create a restricted "ls" style program that shows (on the cli) far less info than what the Finder or Windows Explorer does.

You seem to conflate the CLI with the "canonical representation" of what actually happens in the OS/FS etc. But it's just a textual representation of it, nothing more.

What actually happens is a series of process starts, method calls, and system calls.

Whether you say it by printing stuff out (like early computers), in a cli (like UNIX systems), in a GUI, or even in VR or "PC-to-brain interface" in the future, it's the same underlying thing.

>Sorry to break your little utopia apart, but "most smartphones" run Linux or generally work with hierarchic filesystems, which is totally opposite of "no current working directory".

That's totally irrelevant to what I wrote.

My point is about those platforms not having a CLI as a user accessible object -- but only providing a GUI representation -- and users getting by just fine with that. Including the vast majority of OS X and Windows users who don't venture into the terminal at all.

>And that's why I don't insist to use them or even learn them. What I insist is to learn how the compiler is called

Again, you conflate the cli interface to the compiler to some canonical way about how "the compiler is called".

The compiler is called in many ways.

The cli is one, it's programmatic interface is another.

In fact both the gui window "run compiler with X, Y, Z options" and the cli command command "gcc -X -Y -Z" in the end just end at the same function, that starts the actual process.