Threads for igemnace

  1. 17

    A really useful thing is to always display the error code unless it’s 0. Got used to it real quick and don’t know how I lived without it.

    prompt_show_ec () {
     # Catch exit code
     # Display exit code in red text unless zero
     if [ $ec -ne 0 ];then
      echo -e "\033[31;1m[$ec]\033[0m"
    PROMPT_COMMAND="prompt_show_ec; $PROMPT_COMMAND"
    1. 4

      Good point! I also have a prompt function for it, in zsh (screenshot:

      ### EXIT
      ### prints last exit code
      ### but only if non-zero
      colored_exit_code() {
        echo "%(?..${nl}%F{8}exit %F{1}%?)%f"
      1. 1

        Indispensable for prototyping and shell scripting.

        I also like some of the oh my zsh themes and the like that will color code this for you as well.

      1. 1

        2015 Macbook Pro, 16GB RAM. Primary laptop but I do most of my development SSH-ed into an OVH bare metal instance. It’s still going strong although I could replace the battery. When this one dies I’ll definitely get another macbook. They’re the only hardware I trust to work without any modifications necessary, best battery life, and best laptop keyboards. I’ve tried to like XPS and Lenovo laptop keyboards but it’s the control/shift/alt keys that are always too small, making it harder to touch type.

        1. 1

          My work machine is similar: 2015 Macbook Pro, 8GB RAM. Company laptop, hosts all company code, runs all the builds. Same – going really strong, really only the battery that’s degraded but that’s also because of my usage (I keep it plugged it at all times).

          I typically work with it by SSHing into it from my Lenovo Ideapad 5 running Linux (which is my daily driver). I feel you on the keyboard. But thankfully, being able to work in a Linux environment I’ve tweaked to fit me like a glove is enough of a tradeoff for me than to work directly on my MBP.

        1. 11

          Oh, I have quite a few!

          For shell aliases and functions:

          vg: Shell function to open grep results directly in Vim using the quickfix. A bit of expounding here, in a small blog post.

          • rg foo (with ripgrep) to simply view results
          • vg foo to use the results as a jumping point for editing/exploring in Vim.

          A ton of aliases to shorten frequently used commands. Few examples:

          • When I want to sync a Git repo, I run gf to fetch, glf to review the fetched commits, then gm to merge. git pull if I’m lazy and want to automatically merge without reviewing
          • glp to review new local commits before pushing with gp. Both glf (“git log for fetch”) and glp (“git log for push”) are convenient because my shell prompt shows me when I’m ahead or behind a remote branch:
          • tl to list tmux sessions, then ta session to attach to one. I name tmux sessions with different first letters if I can help it, so instead of doing ta org or ta config, I can be as short as ta o and ta c

          Also, “aliases” for Git operations that I relegate to Fugitive. Technically these are shell functions, but they exist mostly just to shorten frequently used commands.

          • Instead of gs for git status, I do vs and open the interactive status screen from Fugitive (which after a recent-ish update a few years ago, is very Magit-like, if you’re more familiar).
          • When I’m faced with a merge conflict, I do vm to immediately open Vim targeting all the merge conflicts. The quickfix is populated, and I jump across conflicts with [n and ]n thanks to a reduced version of vim-unimpaired.

          For scripts:

          First off, an easy way to manage my PATH scripts: binify my scripts so they go into PATH, binedit if I need to make a quick edit.

          ez: Probably my favorite one. A script to run FZF, fuzzy-find file names, and open my editor for those files. Robust against whitespaces and other special characters. I also have a short blog post expounding on it.

          watchrun: A convenience command to watch paths with inotifywait and run a command for each changed file. For example, watchrun src -- ctags -a to incrementally update a tags file.

          notify-exit: Run a command and shoot off a libnotify notification if it finishes (whether with a successful exit code or not). I have it aliased to n for brevity (using a symlink). For example, n yarn build to kick off a long-running build and be notified when it’s done.

          • Also, a remote counterpart rnotify-exit, which I have aliased to rn (using a symlink). For example, rn ian@hostname yarn build on a remote machine (within my LAN) to kick off a build, and have it still notify on my laptop.

          And a slew of scripts that are a bit more integrated with tools I use, e.g.:

          I normally keep these in fixed locations, so everything I’ve accrued naturally over the years should be here:

          1. 4

            I used to have a ton of these git shortcuts but at some point I threw them out again because I kept forgetting them. The only thing I use daily is git up which is git pull --rebase.

            1. 1

              I had a similar problem and only kept branch-history which showed me the one line commit diff between my feature branch and dev.

            2. 2

              notify-exit: that’s one of those ideas that is so great you facepalm and ask yourself why you never thought of it before. I’m adding this to my config tomorrow.

              1. 1

                ez, is great, thanks for sharing!