3 ms·

Big use case - you want to run a helper script that is located relative to your original script + this is a package of scripts that you move between machines an

• e12e 6y ago
  That is what $PATH is for?
  • 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 ago
      I 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".