5 ms·

sd – a cozy nest for your scripts

Zababa 4y ago
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.
- compressedgas 4y ago
  https://rhodesmill.org/brandon/2009/commands-with-comma/ https://rhodesmill.org/brandon/2009/commands-with-comma/
laurent123456 4y ago
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.
- dradtke 4y ago
  sd seems to provide a description for the command, too, which your solution wouldn't provide.
- davidpfarrell 4y ago
  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 '.'
- ianthehenry 4y ago
  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.
hrbf 4y ago
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/completions/s.fish 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 https://news.ycombinator.com/item?id=24246069
infinitezest 4y ago
I wrote a very similar tool that optionally uses FZF for auto complete: https://codeberg.org/atomdmac/gosh https://codeberg.org/atomdmac/gosh
eterps 4y ago
Nice tool but the name is a bit unfortunate: https://github.com/chmln/sd https://github.com/chmln/sd (a modern sed alternative)
- ianthehenry 4y ago
  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 :)
natmaka 4y ago
Part of the underlying challenge was tackled in various ways, for example: https://directory.fsf.org/wiki/Depot https://directory.fsf.org/wiki/Depot
rsolva 4y ago
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 :)
davidpfarrell 4y ago
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 https://github.com/TekWizely/run
- ianthehenry 4y ago
  Yep, sd supports arbitrarily nested command hierarchies.
tpoacher 4y ago
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.

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.

compressedgas 4y ago
https://rhodesmill.org/brandon/2009/commands-with-comma/ https://rhodesmill.org/brandon/2009/commands-with-comma/

laurent123456 4y ago

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.

dradtke 4y ago
sd seems to provide a description for the command, too, which your solution wouldn't provide.
davidpfarrell 4y ago
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 '.'
ianthehenry 4y ago
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.

hrbf 4y ago

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/completions/s.fish 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 https://news.ycombinator.com/item?id=24246069

infinitezest 4y ago

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

eterps 4y ago

Nice tool but the name is a bit unfortunate: https://github.com/chmln/sd https://github.com/chmln/sd (a modern sed alternative)

ianthehenry 4y ago
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 :)

natmaka 4y ago

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

rsolva 4y ago

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 :)

davidpfarrell 4y ago

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 https://github.com/TekWizely/run

ianthehenry 4y ago
Yep, sd supports arbitrarily nested command hierarchies.

tpoacher 4y ago

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.