3 ms·
Assuming it's only 1 set of scripts. I do something similar with scripts that are within projects. There are scripts named the same but vary due to each projec
by rovr138 6y ago
Assuming it's only 1 set of scripts.
I do something similar with scripts that are within projects. There are scripts named the same but vary due to each project being different so I can't use $PATH (unless I export it every single time I change projects and open a terminal for it)
Commands are relative and sometimes these can be executed by other things. Other scripts, cron, etc. depending on the environment and the use. So, first step, cd into the correct directory and then run everything relative to it.
- e12e 6y agoI mean, whatever works for you, obviously - there's no true way - but this sounds fragile - and perhaps more importantly - like working against the grain of shell/Unix. I would generally say that state belongs in environment variables (and arguments) - and/or files/input streams. Not partially hard-coded in partial scripts. I suppose I could see a "framework" like: ./projX/setup ./projX/job1 ./projX/job2 ./projX/cleanup But I'd still prefer setup and friends to accept a path (not PATH) as first argument or whatever. Rather than assuming a relative path. Maybe even factor most of this into something that could live under /opt/bin or whatever. Especially for cron I'd rather see: /opt/projX/scripts/mangle /opt/projX Rather than just the first part with an implicit argument of "parent of containing folder".