On Sun, Apr 14, 2013 at 1:33 AM, Tony Robinson
<deusexmachina667 () gmail com> wrote:
Here's what I get when I run barnyard2 with -v:
______ -*> Barnyard2 <*-
/ ,,_ \ Version 2.1.13-BETA (Build 325)
Current Master is at 2-1.13-BETA Build 325 which
was synced with master just a few days ago.
I would suggest that instead of fetching master you could mabey
get the users to choose which version they want to download
by using the tag page https://github.com/firnsy/barnyard2/tags
wget --no-check-certificate https://github.com/firnsy/barnyard2/tags -q
grep -B1 tag-name tags
And from there you can directly get version
www.github.com/firnsy/barnyard2/archive/vxxxxx.zip or .tar.gz
- The way my script installs barnyard 2 is that I configure the
barnyard2.conf file via sed-foo and tell it where to find the sid and
gen-msg.map, among other settings.
- I don't trust my sed-foo that much, so I use the -S and -G options to
barnyard2 where to find the sid and gen-msg.map files via the command
as a Safety Net of sorts.
- In the past, there would be no conflict here; if the conf file said one
thing and the command line said another, the command line would win and
barnyard 2 would use the -S and -G arguments via the command line.
- With the copy of barnyard 2 I pulled via github, here's the errors I
If i could suggest something to mabey help out: Wouldn't it be
possitble that instead of using sed to replace information in a
templated configuration file,
that the script would actually generate the configuration file? Or
mabey use clear defined marker thus making sed operation more
ex: ##SID-MAP-FILE## ##CONFIGURATION-INTERFACE## ##DATABASE-USER##, etc...
- The errors are verbose enough for me to understand what happened, I'm
curious what prompted the change in how arguments are parsed/accepted
The main changes comes with 2-1.13-BETA and support for sid-msg.map v2
This can help prevent issue where people would declare two times
one being v1 and the other being v2.
Also there was some possible issue the way processing of the command
line and the configuration
option where done, thus the "new behavior". Since processing of the
file was done at parsing time and not
at configuration merging time (when command line and configuration is
Now processing is done after configuration and command line is merged
and there is no way to know
if command line or configuration file is the good file, thus the
error, in this case mabey the error should't trigger
since the command line and the configuration line are pointing to the
same file (and i fix this before release).
Hope this answered your question.