Hey guys, just want to share with you my bash script. Its purpose is to update QW related sources using git, compile new binary and deliver it to proper place. Right now it compile following projects:

* ktx
* mvdparser
* mvdsv
* qtv
* qwfwd

I chose Deurk as a primary location. I've been using Jite as well but I'm pretty sure somebody have mentioned that Deurk's are now 'official ones'. If that's incorrect, please let me know.

Source along with description and usage examples is available here. Feel free to grab it. I hope it will make your life easier.

(Edited 2015-11-10, 15:16)

sounds very nice!

very handy way of keeping servers up to date. And since nQuakesv binaries are only updated when proper testing is done, this is a handy alternative

good job d2

Good initiative!

Got some remarks though, like unnecessary bash dependancy (I don't even have bash). I'll send you a pull request when I have time for it

Thanks guys ;-)

@dimman: which interpreter you are using on daily basis? Will /bin/sh work for you?

I'm using zsh. But there's no need for such a simple script as this to be bound to a specific shell. Should be fairly trivial to make it "/bin/sh compatible".

Yep, done. Check my latest commit to see changes ;-) I think that's what you wanted.

(Edited 2015-11-10, 22:10)

Yeah it's better Use printf instead of echo since some shells use 'echo -e' equivalent as default and some dont, printf is much more portable and robust. Just remember to add a \n if you want a newline.

There are some other things that I saw:For instance you can't check the existance of git (or anything) by comparing output of which to the empty string, you must supress the output and look at return value instead.

You don't check the return value of basically anything, so many things can go wrong without doing anything about it

Some other stuff of less importance: There's no need to wrap constants within {}, and string literals doesn't need to be within quotes. I'd say it's nicer to check $# instead of doing ${1} for instance.

fair point, will change this in next commit.



Well, I tend to disagree. For 'which' command it's enough. There are only 3 different exit codes available: 0 - everything is OK, 1 - not found or not executable, 2 - wrong argument was supplied in command line. It's hard to make a mistake here. Or do I miss some specific scenario?



I am checking key things with 'b_check_status'. If one of them fails, scripts is stopped with proper message displayed to user. If you don't see a call to this check, then I made assumtion that this check is not required in that place. Happy to add more check if you have any particular place in mind.

I was about to use more generic approach, like 'catch all' error handler, but you wouldn't probably like it as it depends on 'pipefail' and 'errtrace' and that's exclusively bash thing :-)



That's important when you are doing indirect references to variables and it's better to operate on one with curly brackets. I guess it's from the old days when I kept compatibility in my scripts with Solaris boxes :-) After all, you will not print some portion of variable without '{}' and it's definitely a bad idea to use mixed statements with and without such brackets in the same script. Just my opinion.

"which donkey" will output "donkey not found" (might be shell dependant) so it will never be "" unless you supress the output, and if you supress the output you will never see the actual path IF donkey exist, so you must check the return value.

Nope, that's shell-specific behaviour, 'zsh' to be specific as I checked different scenarios with /etc/shells available in Debian. So, let's not zsh-fy this script too much :-) Besides, this will not break anything because I'm not using git command from variable (like '$GIT') but 'git' as a actual word. And as you can see, this is what I meant by 'key thing' and after each git command I'm using b_check_status which will catch probable error like 'git command not found' :-)

I agree though that's perhaps better practice to use exit codes instead of actual command outputs. Will fix that.

EDIT: done, latest commit.

(Edited 2015-11-10, 22:10)

I don't really understand what you are rambling about. I said that the behaviour of `which` might be shell dependant. Your previous solution does not work on all shells. Using the return/exit value is not zsh specific but a portable way of doing it.

Well, I'm not the one who is rambling about (since the beginning). After all, I wrote in 'requirements' section that bash is required to run it, right?

Anything else I should 'fix' or did we finally hit 'dimman-approved' stage for this piece of code?

I'm curious to why you're using eval when calling make?

get a room you two

That's an excellent question dimman :-)

Short answer: for debugging and logging purposes.

Longer answer: I couldn't pass ' > /dev/null 2>&1' under $variable depending on DEBUG being set to 'on' or 'off'. It would simply result in 'make: unable to find >' when it comes to compilation. Shell would treat '>' sign as an filename instead of redirection character. And regular '--silent, --quiet' etc options are not supressing output completely. So, working solution for 'bash' was just to use eval with additional variables but it's not an case for 'sh' scripts. I had to put every significant command into another wrapper to make debugging and logging actually work. Hope that make sense.