Without wishing to prescribe a working method, I/we do things a little differently.
As I'm always repeating to our Junior developers - "a good developer is a lazy developer" and "don't be WET" (WET = We Enjoy Typing, the opposite of DRY - Don't Repeat Yourself). Kind of ironically, I'm breaking DRY by repeating that to the Juniors...
As a result, I never need to connect to anything that doesn't have a full bash installation. Even Docker containers, the images are stripped bare, so don't have bash etc, and if something is wrong within the container, it's either in a volume or the image needs a rebuild. Same for VMs, if it's not a full blown Linux installation, I've no need to connect to it - and if I do need to connect to it, chef deals with sync for me.
FWIW, I also don't rely heavily on bash aliases - about the only two I can think of that I use with any regulatory are ll (which is just ls -latrh) and msg (which will send a message to a user on another TTY in the same host - e.g. msg bob "dw, I got this production issue, grab a coffee").
well it depends on the situation, in my case sometimes I do have to login into machines without Bash and as I mentioned, I've typed more in this couple of comments than in a day of commands, I argue that in this case KISS is more relevant to me, to avoid a couple of key-presses is just irrelevant to me. as I said a couple of minutes of coding has a lot more typing than the saved time, also remembering the aliases has a cognitive cost, that again, to me is not worth it, of course if I where a sysadmin and had to repeat the same commands hundreds of times it would probably be different, or if in your case you never have to deal with machines without bash. Almost everything is a trade-off that has to be evaluated case by case; I just wanted to pointed out the other side of the trade-off. And in that note, DRY is also not a universal law, it also carries it's own trade-offs, to evaluate them and take action in a case by case basis is part of our job.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Without wishing to prescribe a working method, I/we do things a little differently.
As I'm always repeating to our Junior developers - "a good developer is a lazy developer" and "don't be WET" (WET = We Enjoy Typing, the opposite of DRY - Don't Repeat Yourself). Kind of ironically, I'm breaking DRY by repeating that to the Juniors...
As a result, I never need to connect to anything that doesn't have a full bash installation. Even Docker containers, the images are stripped bare, so don't have bash etc, and if something is wrong within the container, it's either in a volume or the image needs a rebuild. Same for VMs, if it's not a full blown Linux installation, I've no need to connect to it - and if I do need to connect to it, chef deals with sync for me.
FWIW, I also don't rely heavily on bash aliases - about the only two I can think of that I use with any regulatory are
ll(which is justls -latrh) andmsg(which will send a message to a user on another TTY in the same host - e.g.msg bob "dw, I got this production issue, grab a coffee").well it depends on the situation, in my case sometimes I do have to login into machines without Bash and as I mentioned, I've typed more in this couple of comments than in a day of commands, I argue that in this case KISS is more relevant to me, to avoid a couple of key-presses is just irrelevant to me. as I said a couple of minutes of coding has a lot more typing than the saved time, also remembering the aliases has a cognitive cost, that again, to me is not worth it, of course if I where a sysadmin and had to repeat the same commands hundreds of times it would probably be different, or if in your case you never have to deal with machines without bash. Almost everything is a trade-off that has to be evaluated case by case; I just wanted to pointed out the other side of the trade-off. And in that note, DRY is also not a universal law, it also carries it's own trade-offs, to evaluate them and take action in a case by case basis is part of our job.