[Joker_vD]

> I wonder why are dofiles have to be on remote machines?

Because the processes that use them run on the remote machines.

> I type an alias, the ssh client expands it on my local machine and send complex commands to remote.

This is not how SSH works. It merely takes your keystrokes and sends them to the remote machine, where bash/whatever reads and processes them.

Of course, you can have it work the way you imagine, it's just that it'd require a very special shell on your local machine, and a whole RAT client on the remote machine, which your special shell should be intimately aware about. E.g. TAB-completion of files would involve asking the remote machine to send the dir contents to your shell, and if your alias includes a process substitution... where should that process run?

[est]

> the processes that use them run on the remote

Yes but but does the process have to read from a file system dotfile, instead of some data fetched over a ssh connection?

> your alias includes a process substitution

Very valid point. How about a special shell only provides sys calls and process substitution on remote, the rest runs on local client, and communicate via ssh?

I understand this will make client "fat" but it's way more portable.

[Joker_vD]

> Yes but but does the process have to read from a file system dotfile, instead of some data fetched over a ssh connection?

Well, no. But if you didn't write that program (e.g. bash or vim), you're stuck with what their actual logic is. Which is "read a file from the filesystem". You can, of course, do something like mounting your local home directory onto the remote's filesystem (hopefully, read-only)... But in the end of the day, there are still two separate machines, and you have to mend the divide somehow, and it'll never be completely pretty, I'm afraid.

> How about a special shell only provides sys calls and process substitution on remote.

Again, as I said, lots of RATs exist, not all of them malicious. But to make "the rest runs on local client" you need to write what essentially will end up a "purely remote-only shell". Essentially, all the parts of bash that manage parsing, user interaction and internal state tracking but without actual process management. Perhaps it's a good idea, actually; but untangling the mess of bash source is not going to be easy.

The current solution of "have a completely normal, standard shell run on the remote and stretch the terminal connection to it over the network" is Good Enough for most of people. Which is not surprising given that that's the environment in which UNIX and its shell were originally implemented.