User panel stuff on forum
  15 posts on 1 page  1
Server Talk
2015-11-10, 09:59
Administrator
114 posts

Registered:
Sep 2013
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)
play.quake1.pl
2015-11-10, 12:45
Administrator
1265 posts

Registered:
Jan 2006
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
never argue with an idiot. they'll bring you back to their level and then beat you with experience.
2015-11-10, 15:10
Administrator
1025 posts

Registered:
Apr 2006
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
2015-11-10, 15:18
Administrator
114 posts

Registered:
Sep 2013
Thanks guys ;-)

@dimman: which interpreter you are using on daily basis? Will /bin/sh work for you?
play.quake1.pl
2015-11-10, 15:20
Administrator
1025 posts

Registered:
Apr 2006
d2 wrote:
Thanks guys ;-)

@dimman: which interpreter you are using on daily basis?

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".
2015-11-10, 15:29
Administrator
114 posts

Registered:
Sep 2013
dimman wrote:
d2 wrote:
Thanks guys ;-)

@dimman: which interpreter you are using on daily basis?

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)
play.quake1.pl
2015-11-10, 15:33
Administrator
1025 posts

Registered:
Apr 2006
d2 wrote:
dimman wrote:
d2 wrote:
Thanks guys ;-)

@dimman: which interpreter you are using on daily basis?

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 last commit to see changes ;-) I think that's what you wanted.

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.
2015-11-10, 15:48
Administrator
114 posts

Registered:
Sep 2013
dimman wrote:


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.



fair point, will change this in next commit.

dimman wrote:

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.


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?

dimman wrote:

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


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 :-)

dimman wrote:

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.


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.
play.quake1.pl
2015-11-10, 15:56
Administrator
1025 posts

Registered:
Apr 2006
d2 wrote:
dimman wrote:

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.


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?

"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.
2015-11-10, 16:08
Administrator
114 posts

Registered:
Sep 2013
dimman wrote:

"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)
play.quake1.pl
2015-11-10, 18:12
Administrator
1025 posts

Registered:
Apr 2006
d2 wrote:
dimman wrote:

"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, last commit.

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.
2015-11-10, 19:50
Administrator
114 posts

Registered:
Sep 2013
dimman wrote:

[...]
I don't really understand what you are rambling about.
[...]


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?
play.quake1.pl
2015-11-10, 22:27
Administrator
1025 posts

Registered:
Apr 2006
d2 wrote:
dimman wrote:

[...]
I don't really understand what you are rambling about.
[...]


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?
2015-11-11, 10:19
Administrator
1265 posts

Registered:
Jan 2006
get a room you two
never argue with an idiot. they'll bring you back to their level and then beat you with experience.
2015-11-11, 12:15
Administrator
114 posts

Registered:
Sep 2013
dimman wrote:
I'm curious to why you're using eval when calling make?


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.
play.quake1.pl
  15 posts on 1 page  1