5 ms·

I consider scripts to be functional documentation, so I write a lot of them, usually shell scripts but Ruby and Python, too. Any task that I might want to perf

by deeg 6y ago

I consider scripts to be functional documentation, so I write a lot of them, usually shell scripts but Ruby and Python, too. Any task that I might want to perform again, or tasks for someone else, gets a script if possible. All of my repos have a /scripts directory. It can take some work to write and debug but in the end when it's working you know you have correct "documentation". Text and wiki documentation may look right but you can't be sure. Just today someone on my team was trying to create a particular build on Jenkins but was using the wrong build parameters, which were copied from wiki; the previous owner of the wiki had neglected a few changes. But the script worked!

kinix 6y ago
I've found recently that Makefiles are my best friend for this kind of thing, even if it's just wrapping existing commands with the right arguments and conventions for the project. Being able to do a simple `make build`, instead of remembering all the right command syntax, repositories etc is so much nicer that having to trawl through a README in a couple of months time for how I was using this thing
- bjonnh 6y ago
  +1 I've been using makefiles more and more. And the nice thing is, if you don't have hidden dependencies you can just do a make -jn and get parallelism.
flukus 6y ago
I also like having a script per project that will get auto loaded when you cd in. An example from a current project: #my vimrc knows what to do with this export VIM_TAGFILES="$PWD/build/tags,$HOME/.local/var/tags/system,$HOME/.local/var/tags/glib-2.0" export CFLAGS=' -g -O0 ' function autobuild { (mkdir -p build cd build while true; do make make deploy inotifywait -qr -e close_write,delete ../cgi ../test ../Makefile.am ../migrate.sql; done) } function watch { tail -f build/app.log build/deploy/app.log } Over time they'll end up with a bunch of other random things. I've tried abstracting a lot of these to their own scripts but every project proves just different enough to make that more complicated. And most of them are personalized enough that they don't go into the project itself. Another "super power" for shell scripts is writing completion scripts (https://iridakos.com/programming/2018/03/01/bash-programmable-completion-tutorial https://iridakos.com/programming/2018/03/01/bash-programmabl...). I've had some insanely useful one's do things like look up database values to mimic a large complicated third party product, going through it's UI inputting repetitive info, copying files around, etc was reduced to fake-tool<tab><tab><tab><tab>.
- misev 6y ago
  You may find prm useful for this purpose, it lets you create projects with start/stop scripts that get executed when you do `prm start project` or `prm stop project`. I use it to quickly switch to the right directories, open editors, services, etc. needed by a project. 1. https://github.com/EivindArvesen/prm https://github.com/EivindArvesen/prm
  - NateEag 6y ago
    `direnv` will automatically activate and deactivate a project-specific shell env for you when you change directories. I like to put scripts for the project in a `bin/` directory then use direnv to put the project's `bin/` on PATH. I've leaned more and more towards mirroring the *nix directory structure in my projects. `etc/` and `bin/` are two top-level folders in a lot of my projects at work.

by deeg 6y ago

kinix 6y ago

I've found recently that Makefiles are my best friend for this kind of thing, even if it's just wrapping existing commands with the right arguments and conventions for the project. Being able to do a simple `make build`, instead of remembering all the right command syntax, repositories etc is so much nicer that having to trawl through a README in a couple of months time for how I was using this thing

bjonnh 6y ago
+1 I've been using makefiles more and more. And the nice thing is, if you don't have hidden dependencies you can just do a make -jn and get parallelism.

flukus 6y ago

I also like having a script per project that will get auto loaded when you cd in. An example from a current project: #my vimrc knows what to do with this export VIM_TAGFILES="$PWD/build/tags,$HOME/.local/var/tags/system,$HOME/.local/var/tags/glib-2.0" export CFLAGS=' -g -O0 ' function autobuild { (mkdir -p build cd build while true; do make make deploy inotifywait -qr -e close_write,delete ../cgi ../test ../Makefile.am ../migrate.sql; done) } function watch { tail -f build/app.log build/deploy/app.log } Over time they'll end up with a bunch of other random things. I've tried abstracting a lot of these to their own scripts but every project proves just different enough to make that more complicated. And most of them are personalized enough that they don't go into the project itself. Another "super power" for shell scripts is writing completion scripts (https://iridakos.com/programming/2018/03/01/bash-programmable-completion-tutorial https://iridakos.com/programming/2018/03/01/bash-programmabl...). I've had some insanely useful one's do things like look up database values to mimic a large complicated third party product, going through it's UI inputting repetitive info, copying files around, etc was reduced to fake-tool<tab><tab><tab><tab>.

misev 6y ago
You may find prm useful for this purpose, it lets you create projects with start/stop scripts that get executed when you do `prm start project` or `prm stop project`. I use it to quickly switch to the right directories, open editors, services, etc. needed by a project. 1. https://github.com/EivindArvesen/prm https://github.com/EivindArvesen/prm
- NateEag 6y ago
  `direnv` will automatically activate and deactivate a project-specific shell env for you when you change directories. I like to put scripts for the project in a `bin/` directory then use direnv to put the project's `bin/` on PATH. I've leaned more and more towards mirroring the *nix directory structure in my projects. `etc/` and `bin/` are two top-level folders in a lot of my projects at work.