261–270 of 408 posts
The most useful script I wrote is one I call `posh`. It shorten a file path by using environment variables. Example: $ posh /home/ramrachum/Dropbox/notes.txt $DX/notes.txt Of course, it only becomes useful when you define a bunch of environment variables for the paths that you use often. I use this a lot in all of my scripts. Basically whenever any of my script prints a path, it passes it through `posh`.
Over time that's grown to an @foo script for every project I work on, every place I frequent that has some kind of specific setup. They are prefixed with an @ because that only rarely conflicts with anything, and tab-complete helps me remember the less frequently used ones.
The @project scripts setup the whole environment, alias the appropriate build tools and versions of those tools, prepare the correct IDE config if needed, drop me in the project's directory, etc. Some start a VPN connection because some of my clients only have git access over VPN etc.
Because I've worked on many things over many years, most of these scripts also output some "help" output so I can remember how shit works for a given project.
Here's an example:
# @foo
PROJECT FOO
-----------
VPN Connection: active, split tunnel
Commands:
tests: mvn clean verify -P local_tests
build all components: buildall
Tools:
java version: 17.0.16-tem
maven version: 3.9.11
I have a bunch, but one that I rarely see mentioned but use all the time is memo(1) ( https://github.com/aktau/dotfiles/blob/master/bin/memo ). It memoizes the command passed to it. $ memo curl https://some-expensive.com/api/call | jq . | awk '...' Manually clearing it (for example if I know the underlying data has changed: $ memo -c curl https://some-expensive.com/api/call In-pipeline memoization (includes the input…
> trash a.txt b.png moves `a.txt` and `b.png` to the trash. Supports macOS and Linux. The way you’re doing it trashes files sequentially, meaning you hear the trashing sound once per file and ⌘Z in the Finder will only restore the last one. You can improve that (I did it for years) but consider just using the `trash` commands which ships with macOS. Doesn’t use the Finder, so no sound and no ⌘Z, but it’s fast, offici…
I am not the author, but my bet is that he didn't know of its existence. The best part about sharing your config or knowledge is that someone will always light up your blind spots.
Yes! I will take this as a chance to thank every people who shared their knowledge on the Internet. You guys are so freaking awesome! You are always appreciated.
A big chunk of my whole life's learning came from all the forums that I used to scour through, hours after hour! Because these awesome people always sharing their knowledge, and someone adding more. That's what made Internet, Internet. And all is now almost brink of loss, because of greedy corporates.
This habit also helped me with doom-scrolling. I sometimes, do doomscroll, but I can catch it quickly and snap out of it. Because, my whole life, I always jumped in to the rabbit holes, and actually read those big blog posts, where you had those `A-ha` moments, "Oohh, I can use that", "Ahh, that's clever!".
When, browsing, do not give me that, by brain actually triggers, "What are you doing?"
Later, I got lazy, which I am still paying for. But I am going to get out of it.
Never stop jumping into those rabbit holes!! Well, obviously, not always it's a good rabbit hole, but you'll probably come out wiser.
Earlier quoted context omitted.
You can apply your dotfiles to servers you SSH into rather easily. I'm not sure what your workflow is like but frameworks like zsh4humans have this built in, and there are tools like sshrc that handle it as well. Just automate the sync on SSH connection. This also applies to containers if you ssh into them.
I'm guessing you haven't worked in Someone Else's environment? The amount of shit you'll get for "applying your dotfiles" on a client machine or a production server is going to be legendary. Same with containers, please don't install random dotfiles inside them. The whole point of a container is to be predictable.
Aren't you therefore optimizing for 1% of the cases, but sabotaging the 99%?
I've written on this before, but I have an extensive collection of "at" scripts. This started 25+ years ago when I dragged a PC tower running BSD to a friend's house, and their network differed from mine. So I wrote an @friend script which did a bunch of ifconfig foo. Over time that's grown to an @foo script for every project I work on, every place I frequent that has some kind of specific setup. They are prefixed wi…
Earlier quoted context omitted.
I don’t even get an account on someone else’s server. There’s no need for me to log in anywhere unless it’s an exceptional situation.
This doesn't make sense. You said you were already using someone else's environment. You can't later say that you don't. Whether or not shell access makes sense depends on what you are doing, but a well written application server running in a cloud environment doesn't need any remote shell account. It's just that approximately zero typical monolithic web applications meet that level of quality and given that 90% of "…
Earlier quoted context omitted.
Besides many nix computers I also have wife, dog, children, chores, shopping to be done. Unlike when I was young engineer I could stay all night fiddling with bash scripts and environments.
What does your wife, dog, children, chores, and shopping have to do with custom configuration and scripts? Just set up a Git repo online, put your files there, and take a couple of minutes to improve it incrementally when you encounter inconveniences. And just like that, you made your life easier for a marginal effort.
It's weird how the circle of life progresses for a developer or whatever. - When I was a fresh engineer I used a pretty vanilla shell environment - When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP - Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use…
man, i couldn't live without alias ..='cd ..' or alias ...='cd ../..' to this day, i still get tripped up when using a shell for the first time without those as they're muscle memory now.