3 ms·

> The next line does its best to define the script’s location directory, and then we cd to it. Why? Eh? This breaks all relative path arguments: /path/to/

by koolba 6y ago

> The next line does its best to define the script’s location directory, and then we cd to it. Why? Eh? This breaks all relative path arguments: /path/to/foo.sh bar.txt If you need to reference relative path data internally then that should be hidden from the caller by that same logic, but used only internally.

saurik 6y ago
Yeah: I almost never want that... if you remarkably want to source files relative to the script location instead of the working directory, I will argue you usually want to do that with a variable for the directory, except in very even-more-special circumstances (in which case I have done something similar to this article).
- InfiniteRand 6y ago
  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 and/or share with co-workers
  - 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".
giberti 6y ago
Definitely an opinionated implementation. It doesn’t make sense for generalized scripts that automate routine tasks. But for some maintenance, build, test, or deploy scripts that only ever perform a specialized job from a single location, it could be handy. I appreciate that Maciej provided it. Always easier to remove it than have to go find it yourself in the odd script you might need it.
- nemetroid 6y ago
  It's useful when it's useful, but I disagree that it belongs in a minimal template, and especially so without mentioning the obvious drawbacks.
  - imtringued 6y ago
    It's minimal in the sense that it's a small template. It's not "minimal" in the sense that you can't do without every single line of the template. Just remove the parts you don't want. It would defeat its purpose if there were multiple templates that each aim at different things and then you have to decide which template you have to choose. Having two minimal templates is not minimal because of the redundancy.
e12e 6y ago
Yes, this is madness. Apparently this is for some category of utility that is a "bash script", not "a unix style command implemented in bash". Make small utilities, call them for each other, or chain them with pipes. 99% of the time that will make more sense.
dahart 6y ago
I want this feature and use it sometimes in my own scripts, usually in scripts that I’m not passing relative path args to. It’s common enough for me that I like having the script_dir in there for a bash script template, and always trivially easy to comment out the cd command. Did the author do that already? I noticed the article had a sentence about changing directory struck out.

by koolba 6y ago

saurik 6y ago

Yeah: I almost never want that... if you remarkably want to source files relative to the script location instead of the working directory, I will argue you usually want to do that with a variable for the directory, except in very even-more-special circumstances (in which case I have done something similar to this article).

InfiniteRand 6y ago
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 and/or share with co-workers
- 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".

giberti 6y ago

Definitely an opinionated implementation. It doesn’t make sense for generalized scripts that automate routine tasks. But for some maintenance, build, test, or deploy scripts that only ever perform a specialized job from a single location, it could be handy. I appreciate that Maciej provided it. Always easier to remove it than have to go find it yourself in the odd script you might need it.

nemetroid 6y ago
It's useful when it's useful, but I disagree that it belongs in a minimal template, and especially so without mentioning the obvious drawbacks.
- imtringued 6y ago
  It's minimal in the sense that it's a small template. It's not "minimal" in the sense that you can't do without every single line of the template. Just remove the parts you don't want. It would defeat its purpose if there were multiple templates that each aim at different things and then you have to decide which template you have to choose. Having two minimal templates is not minimal because of the redundancy.

e12e 6y ago

Yes, this is madness. Apparently this is for some category of utility that is a "bash script", not "a unix style command implemented in bash". Make small utilities, call them for each other, or chain them with pipes. 99% of the time that will make more sense.

dahart 6y ago

I want this feature and use it sometimes in my own scripts, usually in scripts that I’m not passing relative path args to. It’s common enough for me that I like having the script_dir in there for a bash script template, and always trivially easy to comment out the cd command. Did the author do that already? I noticed the article had a sentence about changing directory struck out.