81–90 of 97 posts
Earlier quoted context omitted.
I can’t recall encountering a system in the last 15 years that didn’t have vim (or at least vi for esoteric things) on it.
Would not be uncommon in a container or purpose-built VM.
Earlier quoted context omitted.
scp my-precious-dotfiles remote:~ trap 'ssh remote rm my-precious-dotfiles' EXIT ssh remote Or you can even bake the trap into the remote bash's invocation, although that'd be a bit harder.
That overwrites the remote dotfiles. Any workarounds?
You can also just place config files anywhere if you know what you then load. That's what I do in my dotfiles, but not exactly like the parent. I also purposefully keep the repo size tiny so it's also just easy to clone. I'd recommend setting a env var so you can always just set that
Also don't forget you can have local vim files. I have a function at the end of my vimrc that looks for '.exrc', '.vim.local', '.nvim.local' in the current directory. Helpful for setting project settings.
I wonder why are dofiles have to be on remote machines? e.g. I type an alias, the ssh client expands it on my local machine and send complex commands to remote. Could this be possible? I suppose a special shell could make it work.
> 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,…
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.
People who choose such a noxious name for their project that it actually dissuades people who might otherwise be users think that says something about those prudish users , but it really says something about them.
Earlier quoted context omitted.
Well, what if it's a separate directory meant exclusively for remote systems alone? And what if the remote mount is read-only, perhaps with a writable layer on top using overlayfs that can be discarded on logout?
This now looks very complex.
Earlier quoted context omitted.
scp my-precious-dotfiles remote:~ trap 'ssh remote rm my-precious-dotfiles' EXIT ssh remote Or you can even bake the trap into the remote bash's invocation, although that'd be a bit harder.
That overwrites the remote dotfiles. Any workarounds?
Earlier quoted context omitted.
Any sufficiently-advanced automated rsync would have a filter for caches.
Except only ssh is filtered. Just commenting on what I see, not what should be
I didn't look closely at the project, but why take the extra step of base64? I do this all the time with tar by itself and it's wire-proof enough to work fine.
Earlier quoted context omitted.
> 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,…
> 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…
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.
Earlier quoted context omitted.
That overwrites the remote dotfiles. Any workarounds?
GNU Stow? https://systemcrafters.net/managing-your-dotfiles/using-gnu-... Keep the alternate sets in different subdirectories.