1. 52
  1.  

  2. 7

    Yeah! I had a very similar idea, only I did it in bash: https://github.com/mikemccracken/hs

    I’ll have to look for some good ideas to steal. I guess better tab completion would probably be nice, but maybe that’s just what I get for using bash. Mine does tab-complete script names…

    One difference is that mine keeps your snippets in a git repo, stores execution times and return codes as git notes, and auto-commits any edits - so you can try to keep snippets in sync across machines.

    1. 4

      This seems like a pretty cool idea and I think I might experiment with some variant of it. I’m already sort of quasi-namespacing stuff in ~/bin, with prefixes like fragment- or filter-. There’s probably a good way to piggyback on that.

      1. 4

        I don’t understand why POSIX shells don’t search with path in the first word of the command. With a command such as git/pull, rc would search any $p in $path and invoke $p/git/pull if it finds the executable there.

        1. 3

          You can opt into this behavior in zsh with setopt PATH_DIRS. But the tab completion is a little wonky: it won’t complete directories, so if you have a deeply nested hierarchy you have to type letters with your keyboard. And, you know, no command descriptions.

          1. 2

            That’s how the rc shell in Plan 9 works (which is also available for *nix, AFAIK). It’s quite nice.

          2. 3

            Great! I’ve been doing something similar with a hobby Haskell project called nixon. I initially started it as a way to invoke and source direnv and nix-shells in various projects, so it’s project aware and can have commands and configuration local to a project. State of it is that it’s a mess, by my own comfortable mess.

            I have been experimenting with using a literate config which defines commands along with documentation. Instead of messing about with shell completions I’m using either rofi (gui) or fzf for completing arguments. And scripts can expand output from other commands, so the idea is to build small, reusable scripts. Plan is to support evaluators for different languages: Haskell, Python, JavaScript, ++.

            I also found your series on learning nix through this. It seems like a valuable resource to suggest to my colleagues wanting to dive down the nix rabbit hole. Thank you for this!

            1. 2

              Really nice, I’m doing something a lot more crude and with like 10% of the functionality, but maybe it’s actually worth adopting this by someone who has put in more than an hour of thought.

              1. 2

                This is a great idea, and maybe someday I’ll implement it with bash completion and stuff. … maybe

                1. 1

                  I have a lot of aliases on my dotfiles and some of them are actually mini scripts. I should try something similar. Good stuff.

                  1. 1

                    Before making them scripts, consider making them functions. It’s much more manageable than having a script and you still get arbitrary arg referencing. Try composing them too, if you have to. But if they’re overwhelming your shell rc, go ahead :)