5 ms·

I'm a big fan of this but I often find it in tension with necessary flexibility. The more flexibility I add to my scripts, the less useful they are for this pur

• chubot 6y ago
  Yeah this is a good question. I lean toward making shell scripts work for a specific project. All the paths should be the same for all developers, so I usually use paths relative to the git repo root of the project. A key point is that when you want to "abstract", then the right way is usually to write a command line tool invoked from shell scripts in multiple projects. That is the natural way to get flexibility and reuse. But otherwise it's a bunch of commands dumped in one place. Examples: http://www.oilshell.org/blog/2020/02/good-parts-sketch.html#semi-automation-with-runsh-scripts http://www.oilshell.org/blog/2020/02/good-parts-sketch.html#... Here's a random example -- some scripts to generate source code as part of the build process: https://github.com/oilshell/oil/blob/master/build/codegen.sh https://github.com/oilshell/oil/blob/master/build/codegen.sh The paths are all hard-coded, which is a good thing. In my mind, the goal is to save time and reduce mistakes. And having a consistent dev environment between everybody on a project is almost a prerequisite for that, and shell can actually enforce that consistency! (i.e. the shell scripts don't work if people have quirks on their machine. They can check the environment too.)