3 ms·
This came up just a few days ago[0], and someone suggested you could use either of these: #!/bin/sh set -e case "$1" in build)
by GordonS 7y ago
This came up just a few days ago[0], and someone suggested you could use either of these:
#!/bin/sh
set -e
case "$1" in
build)
;;
run)
;;
clean)
;;
*)
echo "unknown: $1"; exit 2
;;
esac
OR
#!/bin/sh
set -e
test $# -gt 0
build() {
:
}
run() {
:
}
clean() {
:
}
"$@"
Personally, I find makefiles to be ubiquitous and well-understood, and if I want to do anything complex, I can always put that complexity in a shell script that's called by a make target.
[0] https://news.ycombinator.com/item?id=21735176#21754331 https://news.ycombinator.com/item?id=21735176#21754331
- jtaft 7y agoThe second example is vulnerable to command injection. ./test.sh ls -la
- admax88q 7y ago"vulnerable" It's a shell script as part of your build system. Surely you're not passing untrusted input to your command line are you?
- jtaft 7y agoSomeone might. It's always better not to introduce such code.
- GordonS 7y agoUnless I'm missing something, this seems a bit silly. Why would I be any more likely to type `test.sh rm -rf /` that `rm -rm /`?
- jtaft 7y agoI think you're both right that the risk is low, assuming it's a build script that is to be run locally by a developer. Code tends to get copied and pasted, and can easily sneak into other programs. Programs are integrated in ways which weren't originally intended. It's not a secure coding pattern, and that's why I mentioned it. During security reviews, I would be focusing on more risky vulnerabilities, but I still review and flag findings in build scripts. I'm more concerned with build scripts downloading content over HTTP, or missing security compiler flags, but I digress.