3 ms·

I think you meant "$@" rather than $* (The quotes in "$@" are important.) Also, your script will fall over if any of the paths have spaces in them, such as IN

I think you meant "$@" rather than $* (The quotes in "$@" are important.) Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR. You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables. readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere. Shell scripting isn't easy. It took a year to understand these nuances to the point that they're second-nature, and I'm still discovering new ones. Anything that improves this situation would be a welcome change in my opinion. EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.

Pyxl101 11y ago
To elaborate, the GP should have put quotes around command arguments that included variables. For example: cp $INSTALLDIR/app AppDir/bin Should be: cp "$INSTALLDIR/app" AppDir/bin
xorcist 11y ago
> Shell scripting isn't easy. It took a year to understand That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes. But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language. On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.
- ZenPsycho 11y ago
  > On a side note, what's up with not reading manuals these days? The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script". And of course that's all assuming a manual even exists at all.
chei0aiV 11y ago
Some commands that can help with nuances of shell: Check syntax: sh -n myscript Check for bash-specific syntax: checkbashisms myscript Check for various gotchas: shellcheck myscript Check for style: bashate myscript Check for badness: grep -rE '(wget|curl).\|( sudo)? *(ba|z|)sh' myscript

Pyxl101 11y ago

To elaborate, the GP should have put quotes around command arguments that included variables. For example: cp $INSTALLDIR/app AppDir/bin Should be: cp "$INSTALLDIR/app" AppDir/bin

xorcist 11y ago

> Shell scripting isn't easy. It took a year to understand That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes. But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language. On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.

ZenPsycho 11y ago
> On a side note, what's up with not reading manuals these days? The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script". And of course that's all assuming a manual even exists at all.

chei0aiV 11y ago

Some commands that can help with nuances of shell: Check syntax: sh -n myscript Check for bash-specific syntax: checkbashisms myscript Check for various gotchas: shellcheck myscript Check for style: bashate myscript Check for badness: grep -rE '(wget|curl).\|( sudo)? *(ba|z|)sh' myscript