[HN Gopher] SD: My script directory
___________________________________________________________________
SD: My script directory
Author : sph
Score : 109 points
Date : 2022-12-31 09:20 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jrm4 wrote:
| Love this idea. I've been hacking together something similar,
| only with one big-ass rc file. This might be better.
| sigmonsays wrote:
| any consideration to take the unique match into account?
|
| So instead of writing "sd foo bar" you could write "sd f b" if
| foo and bar are unique?
| isitmadeofglass wrote:
| [dead]
| _dain_ wrote:
| +1 to this. I've been using it for a while.
|
| It doesn't do a great deal, the magic is that it removes _just
| enough_ hassle from the shell scripting process that I write far
| more than I used to.
|
| - I don't have to worry about accidentally giving my scripts
| names that collide with other things on my computer, because they
| all live in the sd namespace. It's kind of like the Vim leader
| key, but for the shell.
|
| - I don't worry about forgetting about my scripts later on,
| because I can browse them with tab completion.
|
| - I'm motivated to write a 1-line documentation comment
| explaining wtf the script does, again because the comment gets
| picked up by the tab-completion and displayed as description.
|
| Now I have a growing collection of little scripts organized with
| sd. Many of them are trivial one-liners. Some of them are even
| just stuff I could accomplish with bash syntax but kept
| forgetting how to do because punctuation is harder to remember
| than words. Previously I would write these things but then forget
| about them later on, negating the point. And the worry of
| forgetting made me not write scripts in the first place. I don't
| have to worry about forgetting to write `set -euo pipefail`
| because it does it for me.
| masukomi wrote:
| > Don't you hate it when you can't find the scripts you need,
| when you need it? Well now there's a better way!
|
| It's a good start, and there are definitely some ideas worth
| stealing there, but I don't think it really solves the core
| problem. Not when you have scripts that cross problem domains, or
| the name isn't very intention revealing, or you've just got
| hundreds of them.
|
| The real key to solving this, is searchable documentation. Yeah,
| I know. No-one wants to write docs. But it doesn't have to be
| hard, and it doesn't have to be much. It just has to be enough
| that when next have a problem that involves say "image
| manipulation" you can ask your system for things that handle
| "images" and have it list them.
|
| That's why I wrote TooLoo:
|
| https://tooloo.dev
|
| TooLoo's not for everyone, but if you've been building up your
| own library of useful utilities then I'd _strongly_ recommend you
| consider the value you'll gain from the combination of a little
| bit of documentation + Full Text Search. Full Text search is, I
| think, really important. I don't want to not find something
| because I searched for "image" instead of "images" or vice versa.
| You need a search engine that'll deal with stemming.
|
| In documenting my tools for TooLoo I found many useful things
| that I'd written and completely forgotten about, and others that
| I'd duplicated because I'd forgotten I already had something like
| that. Now I always start by asking TooLoo if I have something
| relevant, or how to use that relevant thing I haven't touched in
| 3 years.
|
| Anyway. If this type of stuff sounds interesting to you check out
| TooLoo. If TooLoo's not right for you, make something cool for
| yourself that uses Full Text Search to find the stuff you need.
| Most databases have it built in these days: SQLite, PostgreSQL,
| MySQL, MongoDB, etc.
| 5- wrote:
| plan 9 typically has a single /bin directory (a union mount of
| various others), and relative path resolution works with slashes,
| so given a script /bin/aux/wham, it can be run with
|
| % aux/wham
| hiccuphippo wrote:
| This still doesn't help me give my scripts meaningful names ;)
|
| I tend to use rg on my ~/bin and search for a string I hopefully
| put in the script in a comment somewhere. Maybe sd could add an
| apropos feature.
| ilyt wrote:
| One idea would be to have a script that runs every one of them
| with --help and indexes the result
| bombolo wrote:
| You think random scripts I just made to put in ~/bin support
| --help?
| ilyt wrote:
| You haven't put anything else useful for info in it either
| so no difference for you
| hiccuphippo wrote:
| It could also index comments at the top of the file, for
| those of us not diligent enough to add a --help flag
| ilyt wrote:
| I just have template for all the boilerplate around cmdline
| handling for whatever I write in.
| unsafecast wrote:
| From what I can tell, sd has a feature that reads a comment or
| something from your scripts and displays them in the tab
| completion. So 'sd <tab>' would show a summary of commands and
| apropos.
| zeroCalories wrote:
| I've clearly missed something. How is this any better than just
| executing a script in a well organized directory? Seems like I
| lose tab completion without significant benefits.
| Tajnymag wrote:
| sd actually has tab completion and it was one of the reasons
| the author made it
|
| He explains it on his blog: https://ianthehenry.com/posts/sd-
| my-script-directory/
| simonw wrote:
| I love this description of the impact of the tool:
|
| > Being able to type sd new foo command instead of vim
| ~/bin/command, typing the shebang, trying to run it,
| realizing I forgot to make it executable, running it again...
| it's made my life slightly better. And because it's so easy
| to save snippets for later, I find that I'm much more likely
| to do it - and a lot less likely to find myself combing
| through ctrl-r a few months later.
|
| > Otherwise, you know, it's not lifechanging. It won't help
| you to appreciate the smaller beauties all around you. You'll
| still wake up feeling groggy.
| zeroCalories wrote:
| Ah gotcha. That info is in the repo, just didn't get through
| my head the first time. Didn't know tab completion could be
| used like that.
| [deleted]
| wruza wrote:
| Nice tool. But I would think about using traditional "--" for
| passing conflicting arguments to a script instead of really-
| really approach. Double dash means stop processing args and
| pass/use them as is. This way you can e.g. rm a file named "-f"
| or echo a string "-n". rm -- -f echo -- -n
| ianthehenry wrote:
| Yeah, the problem is that I am very likely to write a script
| that takes `--` as an argument, and I don't want to have to
| write `-- --` when I call it. I am very unlikely to write a
| script that takes `--really` as an argument, so it's a little
| less annoying.
| wruza wrote:
| My bad, I failed to think about it in a context of a personal
| launcher... now that you said it, it sounds much more
| reasonable than --!
| DrinkWater wrote:
| This seems to solve problems i never ran into.
| dspillett wrote:
| And you post answers a question I would never have asked, "I
| wonder if this will be useful to DrinkWater".
|
| Different people's behaviour patterns and needs are different,
| not everything is useful to everyone so don't expect everything
| to be useful to you. It isn't something I'll ever use, but I
| can see why it might be a benefit to some (the author describes
| the intended utility pretty well).
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| 8bithero wrote:
| I don't know how you did it but the tone of your README.md forced
| my brain to read it in a Sal Goodman voice! Love it! :D
| amelius wrote:
| How about a tool that does the opposite of Copilot: given a bunch
| of scripts, it generates a human readable synopsis, and perhaps
| even a usage summary and some keywords for each script. Then you
| can easily search for them using grep.
| pedrovhb wrote:
| I love the idea and I'll try it out, but a heads up in case the
| author is around: the name sd clashes with another tool [0],
| which works as an alternative to sed.
|
| I use that one pretty often, so maybe my first managed script
| will be one which symlinks binaries :)
|
| [0] https://github.com/chmln/sd
| ianthehenry wrote:
| Yeah :( https://github.com/ianthehenry/sd/issues/9
|
| The trouble is `sd` is just so easy to type on a qwerty
| keyboard, and it's such a nice mnemonic for "script directory."
| I've thought about renaming it, but I can't think of anything I
| like nearly as much.
| gregwebs wrote:
| You could try using sad instead which has interactive diff
| confirm. https://github.com/ms-jpq/sad
| rgoulter wrote:
| I've found the script runner "just" to be worth using.
| https://github.com/casey/just
|
| just (at a glance) is like a Makefile, but with some nice UX
| improvements that make it worth using. e.g. with `just --choose`,
| it runs fzf against the targets.
| aae42 wrote:
| Just is good stuff for project directories, never tried to use
| it like the author describes `sd`
| Ruarl wrote:
| This is a definite enhancement over my existing "big pile o
| scripts" directory. I plan to dig in later and find out if
| different scripts can run in different pyenv virtualenvs.
| davvid wrote:
| If you're into this kinda thing then then you might be
| interested in my take on improving over a "big pile o scripts"
| (and repos).
|
| https://github.com/davvid/garden
|
| Garden is a multi-repo powertool for running custom commands
| and mashing random shell scripts and loosely-coupled repos into
| a version-controllable config file. If you're weird like me you
| might like it.
| cb321 wrote:
| He already seems to be using Zsh. So, as others have said, just
| putting things `~/bin/blog/` & etc. would (mostly) do the
| trick..(maybe with an almost trivial "new" script to create,
| shebang & chmod).
|
| As unyet mentioned, if you `setopt PATH_DIRS` then you can just
| say `blog/publish`.
|
| This used to be a very popular namespacing device as in
| `/usr/bin/mh/inc` for the MH Mail Handling system where people
| would just type `mh/inc`, but POSIX dropped that behavior for
| `$PATH` search in the "standard" shell (whose standardization had
| a less interactive focus).
| ianthehenry wrote:
| This has come up before, so I probably should mention it in the
| README at this point. There are some differences:
|
| The main feature of sd is the command descriptions in
| autocomplete. PATH_DIRS doesn't include these, so it's hard to
| compare them.
|
| At least by default, PATH_DIRS won't autocomplete nested
| directories. If you have blog/publish, it works fine. If you
| have blog/admin/ssl, you won't get autocompletion for admin.
| You can still _run_ blog /admin/ssl with PATH_DIRS, but the
| subcommands are not discoverable anymore. (I'd love to know if
| there's an option to change this!)
|
| Finally, a trivial new script would be very easy to write, but
| giving it autocomplete for existing directories `new
| blog/admin/whatever` would not be trivial. And an "edit" script
| (which I use more often than new) would be very annoying
| without the same autocomplete. And if you write those, then,
| well, you've basically just implemented sd with
| SD_ROOT=$HOME/bin :)
| ktpsns wrote:
| This reminds me on some weird linux/mac/unix tool people used in
| a project. It changed the PATH (or more generally the ENV) based
| on the current working directory, so they could easily manipulate
| the developers shell from the project git repo. I found this
| terrible and fascinating at the same time. I don't remember the
| name of this tool. Who does?
| Squarex wrote:
| dotenv?
| https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/doten...
| mark_round wrote:
| https://direnv.net/ possibly ?
| razemio wrote:
| Direnv is such a great tool. I use it in all of my projects.
| sph wrote:
| Seconded, I love it and I honestly don't know how people
| deal with configuration without it.
|
| The applications I develop all run in Docker or Podman,
| with configuration passed as environment variables. Direnv
| is excellent in dev mode to configure local env vars such
| as database credentials that only apply to a specific
| project, and you will have to approve any change before
| they take effect, in case you made the mistake of
| committing it. To avoid that, I just have `.envrc` listed
| in my ~/.gitignore
| rgoulter wrote:
| On its own, it's nice for development for setting stuff
| like DB URIs, activating Python virtual environments, etc.
|
| But I find direnv indispensable for how it combines with
| nix (probably asdf would be good enough too) for "project
| specific tools". -- The convenience here is not having to
| remember to install tools system wide in order to work on
| some repository.
| Smaug123 wrote:
| Does direnv have an advantage over `nix develop` in that
| regard?
| rgoulter wrote:
| Yup:
|
| direnv hooks into the shell, so that it adjusts the
| environment variables / PATH when you `cd` into the
| directory. (Well, you do need to run `direnv allow` to
| indicate you trust the `.envrc` file).
|
| (Also, `nix develop` drops you into a bash shell, which
| is annoying coming from fish).
| e3bc54b2 wrote:
| direnv has integration with old nix shell as well as new
| nix develop. It also happens to have lot more editor
| integration that can utilize nix indirectly instead of
| not having access to nix at all.
| PurpleRamen wrote:
| I used to do something similar a long time ago, but over time
| calling everything exclusively through a starter-script turned
| out to be fragile and annoying in some situations. So at some
| point I moved everything back into $BIN and now organize all
| scripts just with prefixes and dedicated starters.
|
| Main advantage of the starter-scripts is that I can use file-
| extensions for my scripts and have dedicated entry-points for
| each functionality. I just let the starters figure out which
| script to call. Additionally if I call the starter without a
| scriptname, It delivers me a selector for selecting a script to
| call, optimized for the context. Normally I use rofi to select a
| script.
|
| And today I even have starters which take into action which
| window is active, and deliver me matching scripts for context-
| aware work. The improvement on productivity with this quite
| simple setup is insane. I used to have launcher-apps like launchy
| or alfred & quicksilver on MacOS. But they were so inflexible
| that they can't compare for me to my customized rofi-experience.
| Really insane how much worth such simplicity can have.
___________________________________________________________________
(page generated 2022-12-31 23:01 UTC)