sd – a cozy nest for your scripts | Hacker News Reader

sd – a cozy nest for your scripts

ianthehenry.com

Instead of having a hierarchy of scripts, why not use namespaces - blog_publish, blog_preview, etc? Then instead of typing `sd blog publish`, you type `blog_publish`. With this you have built-in autocompletion, no need for a third-party tool, a shorter command, and an easy way to see all your scripts at a glance since they'll all be in the same directory.

sd seems to provide a description for the command, too, which your solution wouldn't provide.

I'd say one reason is that nobody wants to type '_' :)

Maybe using '.' would work (ie. blog.publish) but the sub-command pattern (ie space separating) seems well established and slightly easier than typing '.'

You can also set the PATH_DIRS shell option and type, e.g. `blog/publish` if you have a ~/bin/blog directory full of scripts. Easier than an underscore.

I mean, yeah, sd is only a marginal improvement over not sd. It's not a lifechanging script. The differences are:

1. sd makes it easier to create new scripts. Instead of vim ~/bin/blog_publish, writing out the shebang, chmod +x ~/bin/blog_publish, you say `sd blog publish --new`. It sets the permissions and preloads it with a template.

2. Ditto for for other convenience commands: `sd blog publish --edit`, `sd blog publish --cat`.

3. Auto-generates usage text in the autocomplete menu.

4. sd scripts exist in a separate autocomplete namespace from non-sd scripts. b<tab> gives you, you know, bison, binhex, any commands on your PATH. sd b<tab> gives you only your user scripts that start with b.

5. Hierarchical autocomplete is more convenient, if you have more than one level of namespacing.

In case someone is interested in the approach and uses Fish, I’ve created a simple autocompletion.

https://git.herrbischoff.com/dotpr0n/tree/.config/fish/compl...

I’m using “s” for a name instead of “sd” though, since there’s also https://news.ycombinator.com/item?id=24246069

I remember reading a blog post about starting all your scripts names with a comma, so that you can do ,<TAB> and get a list. I've been doing it and it works well. However, I like the namespacing, --help and autocompletion of sd. And I like the idea of hoarding more.

https://rhodesmill.org/brandon/2009/commands-with-comma/

Nice tool but the name is a bit unfortunate:

https://github.com/chmln/sd (a modern sed alternative)

Yeah, sd-the-script-directory pre-dates sd-the-sed-alternative by about 6 months. It seemed like such a good name at the time :)

I wrote a very similar tool that optionally uses FZF for auto complete: https://codeberg.org/atomdmac/gosh

if there was a simple way to alias the whole thing out of the way and have the autocompletion still work, I'd be sold instantly, and use this as a way to get a git-like interface for my bash scripts.

However, while the bash manual says that, in theory, this is a thing, in practice I've found that completion on aliases simply doesn't work. You need to manually redefine the completions from scratch for your aliases.

Given that limitation, I don't see much benefit from this versus a simple wrapper-script using 'case' to redirect to sub-script with their own completion. The latter has the benefit that you don't need a third party library for it.

Still a cool little project though. Kudos. It does feel like one of those "solution looking for a good problem" situations; maybe there's a really nice problem out there that this solves fantastically.

Part of the underlying challenge was tackled in various ways, for example: https://directory.fsf.org/wiki/Depot

This looks like an interesting way to manage scripts globally. I could even see it able to manage n-sub-commands deep (vs usual "command sub-command" - maybe it already does?) by just trying to resolve each argument as a dir until you find a script to execute.

If you're interested in ways to better-manage small scripts and wrappers more locally, please take a look at my project, Run:

https://github.com/TekWizely/run

Yep, sd supports arbitrarily nested command hierarchies.

I have added some basic functions to my .bashrc, which works fine for my use case. This tool might be nice to have when the amount of scripts grow to unmanageable amounts, but I'm not there yet :)

Reply on news.ycombinator.com