Re: DBD::Informix -- Error Installing On Mac OSX

Clive Eisen wrote: > Clive Eisen wrote: >> Jonathan Leffler wrote: >> >> <snip> >> >>> Download Perl 5.10.0 from www.perl.com or any other appropriate >>> source. Compile with the Apple version of GCC - you could set the C >>> compiler to 'cc -m64' to ensure that Perl is built as a 64-bit system. >>> You'll also need to reinstall DBI - and any other modules that you >>> need. And don't install it in the system locations. (I keep my copy >>> under $HOME/perl/ -- but since I have a 32-bit PPC Mac, I don't get to >>> play with CSDK or IDS on it.) >>> >>> >> Has anyone successfully built a 64 bit perl on OSX? I've tried and I >> get just over 1000 errors on make test - >> all relate to loading XS stuff and getting a wrong architecture error. >> >> All I did (to be fair) was ./Configure -Dcc='cc -m64' -des >> >> make && make test >> >> If anyone has the magic incantation to build a 64bit perl so I can >> build DBD::Informix against the 64bit SDK that would be great. >> > Sorry to reply to my own post, but I have solved the problem - so for > anyone else here goes > > #First download perl source - I used 5.10.0 > #untar or unzip as required > #cd into the perlsourcedir/hints and > rm -f darwin.sh > #then > rsync rsync://ftp.linux.activestate.com/perl-current/hints/darwin.sh . > #This gets the bleeding edge darwin hints file that finally supports a > 64 bit build on OSX > cd .. > ./Configure -Dcc='cc -m64' -Duse64bitall -des > make && make test && make install > > #Now you have a 64bit perl in /usr/local/bin that you can link with the > 64bit SDK > > #Only other thing to note is that on OSX LD_LIBRARY_PATH is called > # DYLD_LIBRARY_PATH > #so you will need to do the following > export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ > #before running > /usr/local/bin/perl Makefile.PL > #in the DBD::Informix source dir > > -- > Clive Clive, Thanks for this... I got a moment to install Perl 5.10 today on my Mac Mini using your instructions...haven't tried it on my MacBookPro just yet. Your notes were a big help so very much appreciated! Meddling with Mac is a bit scary since it's not widely known what to do if you screw something up. Perl installed ok. No issues. DBD::Informix installed but I actually had to go in and install it manually because it fails if you don't supply a database, user and password for Informix ahead of time. It would be good to see DBD::Informix set up with the following defaults or a prompt or at least some doc to tell you to do this before running cpan: Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix' set your environment to something like this: export INFORMIXSERVER=demo_on export INFORMIXDIR="/Applications/IBM/informix" export ONCONFIG=onconfig.demo_on export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" export PATH=${INFORMIXDIR}/bin:${PATH} export INFORMIXTERM=terminfoexport TERMCAP=/opt/informix/etc/termcap export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ DBD install variables: export DBI_DBNAME=sysmaster export DBD_INFORMIX_DATABASE=sysmaster export DBD_INFORMIX_USERNAME=informix export DBD_INFORMIX_PASSWORD=informix Or how about a prompt? 8o/ This way it work better since there is no stores database installed with the IDS Developers' Edition. Also the following seems to be Mac-specific: I have had issues getting the Informix environment to work inside Perl scripts without first using a shell environment script. I'm not sure what I'm doing wrong. I'd like to get the Perl scripts to work without first sourcing in an environment file. This works fine on Linux, but on Mac it's not working... If I dot-in the environment file, my Perl scripts connect fine to Informix but without dotting-in the environment it just won't work. I'm not sure what the problem is but it's definitely Mac-only. shell settings: export INFORMIXSERVER=demo_on export INFORMIXDIR="/Applications/IBM/informix" export ONCONFIG=onconfig.demo_on export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" export PATH=${INFORMIXDIR}/bin:${PATH} export INFORMIXTERM=terminfoexport TERMCAP=/opt/informix/etc/termcap export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ export DBI_DBNAME=sysmaster export DBD_INFORMIX_DATABASE=sysmaster export DBD_INFORMIX_USERNAME=informix export DBD_INFORMIX_PASSWORD=informix Here's my informix.env.pl: #!/usr/local/bin/perl ################################################################################ $ENV{'ONCONFIG'} = "onconfig.demo_on" ; $ENV{'INFORMIXSERVER'} = "demo_on" ; $ENV{'INFORMIXDIR'} = "/Applications/IBM/informix" ; $ENV{'INFORMIXSQLHOSTS'} = $ENV{'INFORMIXDIR'} . "/etc/sqlhosts.demo_on" ; $ENV{'DYLD_LIBRARY_PATH'} = $ENV{'INFORMIXDIR'} . "/lib/esql/:" . $ENV{'INFORMIXDIR'} . "/lib/" ; $ENV{'LD_LIBRARY_PATH'} = $ENV{'DYLD_LIBRARY_PATH'} ; $ENV{'PATH'} = $ENV{'INFORMIXDIR'} . "/bin:" . $ENV{'LD_LIBRARY_PATH'} . ":" . $ENV{'DYLD_LIBRARY_PATH'} . ":/usr/local/lib/:" . $ENV{'PATH'} ; $ENV{'TERMCAP'} = $ENV{'INFORMIXDIR'} . "/etc/termcap" ; $ENV{'INFORMIXTERM'} = "terminfo" ; $ENV{'DBI_DBNAME'} = "sysmaster" ; $ENV{'DBD_INFORMIX_DATABASE'} = "sysmaster" ; $DB_USER = "informix" ; $DB_PASS = "informix" ; if ( $ARGV[0] ) { showenv(); } ################################################################################ sub showenv { foreach $key (sort keys(%ENV)) { printf( "%30s = %s\\n", $key , $ENV{$key} ); } } 1; -- Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. Terry Pratchett

InDeep wrote: > Clive Eisen wrote: > >> Clive Eisen wrote: >> >>> Jonathan Leffler wrote: >>> >>> <snip> >>> >>> >>>> Download Perl 5.10.0 from www.perl.com or any other appropriate >>>> source. Compile with the Apple version of GCC - you could set the C >>>> compiler to 'cc -m64' to ensure that Perl is built as a 64-bit system. >>>> You'll also need to reinstall DBI - and any other modules that you >>>> need. And don't install it in the system locations. (I keep my copy >>>> under $HOME/perl/ -- but since I have a 32-bit PPC Mac, I don't get to >>>> play with CSDK or IDS on it.) >>>> >>>> >>>> >>> Has anyone successfully built a 64 bit perl on OSX? I've tried and I >>> get just over 1000 errors on make test - >>> all relate to loading XS stuff and getting a wrong architecture error. >>> >>> All I did (to be fair) was ./Configure -Dcc='cc -m64' -des >>> >>> make && make test >>> >>> If anyone has the magic incantation to build a 64bit perl so I can >>> build DBD::Informix against the 64bit SDK that would be great. >>> >>> >> Sorry to reply to my own post, but I have solved the problem - so for >> anyone else here goes >> >> #First download perl source - I used 5.10.0 >> #untar or unzip as required >> #cd into the perlsourcedir/hints and >> rm -f darwin.sh >> #then >> rsync rsync://ftp.linux.activestate.com/perl-current/hints/darwin.sh . >> #This gets the bleeding edge darwin hints file that finally supports a >> 64 bit build on OSX >> cd .. >> ./Configure -Dcc='cc -m64' -Duse64bitall -des >> make && make test && make install >> >> #Now you have a 64bit perl in /usr/local/bin that you can link with the >> 64bit SDK >> >> #Only other thing to note is that on OSX LD_LIBRARY_PATH is called >> # DYLD_LIBRARY_PATH >> #so you will need to do the following >> export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ >> #before running >> /usr/local/bin/perl Makefile.PL >> #in the DBD::Informix source dir >> >> -- >> Clive >> > > Clive, > > Thanks for this... I got a moment to install Perl 5.10 today on my Mac Mini > using your instructions...haven't tried it on my MacBookPro just yet. > > Your notes were a big help so very much appreciated! Meddling with Mac is > a bit scary since it's not widely known what to do if you screw something up. > Yep. > Perl installed ok. No issues. > > DBD::Informix installed but I actually had to go in and install it manually > because it fails if you don't supply a database, user and password for Informix > ahead of time. > > It would be good to see DBD::Informix set up with the following defaults or > a prompt or at least some doc to tell you to do this before running cpan: > > Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix' > set your environment to something like this: > > export INFORMIXSERVER=demo_on > export INFORMIXDIR="/Applications/IBM/informix" > export ONCONFIG=onconfig.demo_on > export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" > export PATH=${INFORMIXDIR}/bin:${PATH} > export INFORMIXTERM=terminfo> export TERMCAP=/opt/informix/etc/termcap > export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ > > DBD install variables: > > export DBI_DBNAME=sysmaster > export DBD_INFORMIX_DATABASE=sysmaster > export DBD_INFORMIX_USERNAME=informix > export DBD_INFORMIX_PASSWORD=informix > > > Or how about a prompt? 8o/ > > It's an idea - JL will no doubt consider a patch if you submit it :-) > This way it work better since there is no stores database > installed with the IDS Developers' Edition. > > Also the following seems to be Mac-specific: > > I have had issues getting the Informix environment to work inside Perl > scripts without first using a shell environment script. I'm not sure what I'm > doing wrong. I'd like to get the Perl scripts to work without first sourcing > in an environment file. > > This works fine on Linux, but on Mac it's not working... > > Indeed - it's just the DYLD_LIBRARY_PATH - without that DBD::Informix barfs - and once perl has started it seems to be too late to set it! a VERY nasty hack is as follows (substitute you own informidir as appropriate). BEGIN { unless ($ENV{INF_BEGIN_BLOCK}) { $ENV{DYLD_LIBRARY_PATH}='/Applications/IBM/informix/lib/esql/:/Applications/IBM/informix/lib/'; $ENV{INF_BEGIN_BLOCK} = 1; exec 'env',$0,@ARGV; } } -- Clive

Clive Eisen wrote: > Indeed - it's just the DYLD_LIBRARY_PATH - without that DBD::Informix > barfs - and once perl has started it seems to be too late to set it! > > a VERY nasty hack is as follows (substitute you own informidir as > appropriate). > > BEGIN { > unless ($ENV{INF_BEGIN_BLOCK}) { > > $ENV{DYLD_LIBRARY_PATH}='/Applications/IBM/informix/lib/esql/:/Applications/IBM/informix/lib/'; > > $ENV{INF_BEGIN_BLOCK} = 1; > exec 'env',$0,@ARGV; > } > } > > -- > Clive Clive, Where do you put the above code? Sorry if I'm dense, I'm not sure where this belongs. Thanks in advance! -ID-

Beware: prejudices on display. You were warned. On Sun, Nov 2, 2008 at 2:15 PM, InDeep <indeep@indeep.com> wrote: > Clive Eisen wrote: >> Clive Eisen wrote: >>> Jonathan Leffler wrote: >>> >>> <snip> >>> >>>> Download Perl 5.10.0 from www.perl.com or any other appropriate >>>> source. Compile with the Apple version of GCC - you could set the C >>>> compiler to 'cc -m64' to ensure that Perl is built as a 64-bit system. >>>> You'll also need to reinstall DBI - and any other modules that you >>>> need. And don't install it in the system locations. (I keep my copy >>>> under $HOME/perl/ -- but since I have a 32-bit PPC Mac, I don't get to >>>> play with CSDK or IDS on it.) >>>> >>> Has anyone successfully built a 64 bit perl on OSX? I've tried and I >>> get just over 1000 errors on make test - >>> all relate to loading XS stuff and getting a wrong architecture error. >>> >>> All I did (to be fair) was ./Configure -Dcc='cc -m64' -des >>> >>> make && make test >>> >>> If anyone has the magic incantation to build a 64bit perl so I can >>> build DBD::Informix against the 64bit SDK that would be great. >>> >> Sorry to reply to my own post, but I have solved the problem - so for >> anyone else here goes >> >> #First download perl source - I used 5.10.0 >> #untar or unzip as required >> #cd into the perlsourcedir/hints and >> rm -f darwin.sh >> #then >> rsync rsync://ftp.linux.activestate.com/perl-current/hints/darwin.sh . >> #This gets the bleeding edge darwin hints file that finally supports a >> 64 bit build on OSX >> cd .. >> ./Configure -Dcc='cc -m64' -Duse64bitall -des >> make && make test && make install >> >> #Now you have a 64bit perl in /usr/local/bin that you can link with the >> 64bit SDK >> >> #Only other thing to note is that on OSX LD_LIBRARY_PATH is called >> # DYLD_LIBRARY_PATH >> #so you will need to do the following >> export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ >> #before running >> /usr/local/bin/perl Makefile.PL >> #in the DBD::Informix source dir I thanked Clive privately by responding to a private copy of his message. I'll now thank Clive publicly -- I do appreciate what he has done. Thank you, Clive. InDeep said: > Thanks for this... I got a moment to install Perl 5.10 today on my Mac Mini > using your instructions...haven't tried it on my MacBookPro just yet. > > Your notes were a big help so very much appreciated! Meddling with Mac is > a bit scary since it's not widely known what to do if you screw something up. > > Perl installed ok. No issues. > > DBD::Informix installed but I actually had to go in and install it manually > because it fails if you don't supply a database, user and password for Informix > ahead of time. Or have the default already setup. Yes. It does; it will; it isn't likely to change on that score. > It would be good to see DBD::Informix set up with the following defaults or > a prompt or at least some doc to tell you to do this before running cpan: DBD::Informix will not prompt for anything while I'm its guardian. I hate the modules that prompt for things - they are a complete nuisance. I don't mind modules being verbose; that's OK. I don't mind things failing because I've not read the documentation and set the environment correctly, as long as the module reasonably clearly diagnoses the issue. I believe the DBD::Informix is reasonably clear about needing to read the README file -- let me know if you disagree. (I take it as read that if I try something from CPAN and it fails to install but does tell me to read the README file, there are some complex pre-requisites that I need to know about.) > Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix' > set your environment to something like this: Yes, you need a working Informix environment, including a stores database that you can both connect to and use with DBA (minimum, RESOURCE) privileges without supplying user name or password, or you need to set the environment variables to use it. This is part of the README that you are emphatically encouraged to read when anything goes wrong. Even Mac users are expected to read the README. Sorry, but if you don't know what the pre-requisites are, you are on a hiding to nothing. DBD::Informix does its best to deal with you. You have to take a minimal step in the right direction. > export INFORMIXSERVER=demo_on > export INFORMIXDIR="/Applications/IBM/informix" > export ONCONFIG=onconfig.demo_on > export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" > export PATH=${INFORMIXDIR}/bin:${PATH} > export INFORMIXTERM=terminfo> export TERMCAP=/opt/informix/etc/termcap > export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ DBD::Informix does not need ONCONFIG, INFORMIXTERM or TERMCAP set. INFORMIXSQLHOSTS is only needed if you aren't using the standard location ($INFORMIXDIR/etc/sqlhosts) -- that's the same everywhere. INFORMIXDIR is only needed if you aren't using the standard location -- that too is the same on Unix machines (/usr/informix). INFORMIXSERVER is mandatory - period. DYLD_LIBRARY_PATH is the analog of SHLIB_PATH or LD_LIBRARY_PATH or LIBPATH or ... and does need to be set. Again, there is nothing unusual in this. If you can't compile and run ESQL/C programs with the environment you have set, you are not going to be able to compile the Perl module, which is, when all is said and done, an ESQL/C program. I suppose it might be possible to detect that the variable isn't set, but there are circumstances under which it does not have to be set (appropriate settings in /etc/ld.so.conf on Linux, for example). So, it is better, from my perspective, to require that people have a working Informix environment than to test for things that might not be needed. If you want more diagnostics after a failure to test, then provide a patch. Do not provide a patch that is interactive; I will not accept it. > DBD install variables: > > export DBI_DBNAME=sysmaster I've only ever used that as a last resort - if none of the more specific DBD_INFORMIX_* environment variables are set. > export DBD_INFORMIX_DATABASE=sysmaster > export DBD_INFORMIX_USERNAME=informix > export DBD_INFORMIX_PASSWORD=informix There is no way on earth that I am ever going to encourage anyone to use either the sysmaster database or the informix user to install DBD::Informix. Absolutely none. If anything, I would add a proscription from attempting it -- or any sys* database. > Or how about a prompt? 8o/ No. > This way it work better since there is no stores database > installed with the IDS Developers' Edition. It doesn't have to be a stores database -- you get to select the database. If you read the README file. > Also the following seems to be Mac-specific: > > I have had issues getting the Informix environment to work inside Perl > scripts without first using a shell environment script. I'm not sure what I'm > doing wrong. I'd like to get the Perl scripts to work

Jonathan Leffler wrote: >> It would be good to see DBD::Informix set up with the following defaults or >> a prompt or at least some doc to tell you to do this before running cpan: > > DBD::Informix will not prompt for anything while I'm its guardian. > > I hate the modules that prompt for things - they are a complete > nuisance. I don't mind modules being verbose; that's OK. I don't > mind things failing because I've not read the documentation and set > the environment correctly, as long as the module reasonably clearly > diagnoses the issue. I believe the DBD::Informix is reasonably clear > about needing to read the README file -- let me know if you disagree. > As smart as you are, at the level that you are, I am surprised at your arrogance and petulance. The user should be considered your goal, not how maligned you feel and how annoyed you are about the user actually having to actually use your program. How dare they attempt to even come to your alter. Kneel before me and beg for your life user! What say ye! Speak or die! > (I take it as read that if I try something from CPAN and it fails to > install but does tell me to read the README file, there are some > complex pre-requisites that I need to know about.) > Your assumption is weak, arrogant, out of touch with the user, and, to boot, narrow-minded. Good programmers rise to the occasion and perfect their programs, not castigate the user for not reading the instructions. Geez how lame Jonathan, how lame can you get. >> Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix' >> set your environment to something like this: > > Yes, you need a working Informix environment, including a stores > database that you can both connect to and use with DBA (minimum, > RESOURCE) privileges without supplying user name or password, or you > need to set the environment variables to use it. This is part of the > README that you are emphatically encouraged to read when anything goes > wrong. > > Even Mac users are expected to read the README. Sorry, but if you > don't know what the pre-requisites are, you are on a hiding to > nothing. > > DBD::Informix does its best to deal with you. You have to take a > minimal step in the right direction. > >> export INFORMIXSERVER=demo_on >> export INFORMIXDIR="/Applications/IBM/informix" >> export ONCONFIG=onconfig.demo_on >> export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" >> export PATH=${INFORMIXDIR}/bin:${PATH} >> export INFORMIXTERM=terminfo>> export TERMCAP=/opt/informix/etc/termcap >> export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ > > DBD::Informix does not need ONCONFIG, INFORMIXTERM or TERMCAP set. > INFORMIXSQLHOSTS is only needed if you aren't using the standard > location ($INFORMIXDIR/etc/sqlhosts) -- that's the same everywhere. > INFORMIXDIR is only needed if you aren't using the standard location > -- that too is the same on Unix machines (/usr/informix). > INFORMIXSERVER is mandatory - period. > Thanks for that, I know the basics. But it's ok to provide hints and directions. I think you're pretty lazy not to provide some kind of usage instructions right in the installation, > DYLD_LIBRARY_PATH is the analog of SHLIB_PATH or LD_LIBRARY_PATH or > LIBPATH or ... and does need to be set. Again, there is nothing > unusual in this. If you can't compile and run ESQL/C programs with > the environment you have set, you are not going to be able to compile > the Perl module, which is, when all is said and done, an ESQL/C > program. > You should be able to set the $ENV['whatever'} variable in a typical program without having to source in an additional shell environment variable. I want to run programs that are portable and self-contained, without requiring the user to 'dot in' an environment variable from an additional shell file. This ain't rocket surgery. > I suppose it might be possible to detect that the variable isn't set, > but there are circumstances under which it does not have to be set > (appropriate settings in /etc/ld.so.conf on Linux, for example). So, > it is better, from my perspective, to require that people have a > working Informix environment than to test for things that might not be > needed. If you want more diagnostics after a failure to test, then > provide a patch. Do not provide a patch that is interactive; I will > not accept it. > >> DBD install variables: >> >> export DBI_DBNAME=sysmaster > > I've only ever used that as a last resort - if none of the more > specific DBD_INFORMIX_* environment variables are set. > >> export DBD_INFORMIX_DATABASE=sysmaster >> export DBD_INFORMIX_USERNAME=informix >> export DBD_INFORMIX_PASSWORD=informix > > There is no way on earth that I am ever going to encourage anyone to > use either the sysmaster database or the informix user to install > DBD::Informix. > > Absolutely none. > > If anything, I would add a proscription from attempting it -- or any > sys* database. > That's pretty gay. The Developer Edition download creates the sysmaster database by fiat, any other database is optional. After I install IDS I go and install DBD::Informix, I haven't created any other databases yet. Maybe you don't know that there is no stores database after the IDS installation? Your install program should go for the least common denominator, and like I said have a prompt for database, user, and password. Sheesh. >> Or how about a prompt? 8o/ > > No. > >> This way it work better since there is no stores database >> installed with the IDS Developers' Edition. > > It doesn't have to be a stores database -- you get to select the database. > > If you read the README file. > WEAK. YOU'RE FIRED. Stop by HR and pick up your check. -ID-

InDeep wrote: > > WEAK. YOU'RE FIRED. Stop by HR and pick up your check. If you're so fucking smart, how come you couldn't work it out? -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com

InDeep wrote: > > As smart as you are, at the level that you are, I am surprised at your > arrogance and petulance. The user should be considered your goal, not > how maligned you feel and how annoyed you are about the user actually > having to actually use your program. How dare they attempt to even > come to your alter. Kneel before me and beg for your life user! What > say ye! Speak or die! Stop being a cunt. Jonathan gives freely of his time to maintain this, he deserves your thanks, not your abuse. It's his time, he gets to decide how to use it, he gets to decide how it works. If you don't like the way he does it, roll your own and shut the fuck up. You moaning, know-nothing, whingeing, ungrateful, arrogant, petulant, goat-felching twat. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com

InDeep wrote: > Jonathan Leffler wrote: > > >>> It would be good to see DBD::Informix set up with the following defaults or >>> a prompt or at least some doc to tell you to do this before running cpan: >>> >> DBD::Informix will not prompt for anything while I'm its guardian. >> >> I hate the modules that prompt for things - they are a complete >> nuisance. I don't mind modules being verbose; that's OK. I don't >> mind things failing because I've not read the documentation and set >> the environment correctly, as long as the module reasonably clearly >> diagnoses the issue. I believe the DBD::Informix is reasonably clear >> about needing to read the README file -- let me know if you disagree. >> >> > > As smart as you are, at the level that you are, I am surprised at your > arrogance and petulance. The user should be considered your goal, not > how maligned you feel and how annoyed you are about the user actually > having to actually use your program. How dare they attempt to even > come to your alter. Kneel before me and beg for your life user! What > say ye! Speak or die! > As arrogant as you are I'm surprised at your crass stupidity - if you don't like the tools provided, for FREE, for you - then write your own. > > >> (I take it as read that if I try something from CPAN and it fails to >> install but does tell me to read the README file, there are some >> complex pre-requisites that I need to know about.) >> >> > > Your assumption is weak, arrogant, out of touch with the user, > and, to boot, narrow-minded. Good programmers rise to the occasion and > perfect their programs, not castigate the user for not reading the > instructions. Geez how lame Jonathan, how lame can you get. > > > Your assumption that anyone gives a flying f**k about you opinions is lame. >>> Before running /usr/local/bin/perl -MCPAN -e 'install Bundle::DBD::Informix' >>> set your environment to something like this: >>> >> Yes, you need a working Informix environment, including a stores >> database that you can both connect to and use with DBA (minimum, >> RESOURCE) privileges without supplying user name or password, or you >> need to set the environment variables to use it. This is part of the >> README that you are emphatically encouraged to read when anything goes >> wrong. >> >> Even Mac users are expected to read the README. Sorry, but if you >> don't know what the pre-requisites are, you are on a hiding to >> nothing. >> >> DBD::Informix does its best to deal with you. You have to take a >> minimal step in the right direction. >> >> >>> export INFORMIXSERVER=demo_on >>> export INFORMIXDIR="/Applications/IBM/informix" >>> export ONCONFIG=onconfig.demo_on >>> export INFORMIXSQLHOSTS="/Applications/IBM/informix/etc/sqlhosts.demo_on" >>> export PATH=${INFORMIXDIR}/bin:${PATH} >>> export INFORMIXTERM=terminfo>>> export TERMCAP=/opt/informix/etc/termcap >>> export DYLD_LIBRARY_PATH=$INFORMIXDIR/lib/esql/:$INFORMIXDIR/lib/ >>> >> DBD::Informix does not need ONCONFIG, INFORMIXTERM or TERMCAP set. >> INFORMIXSQLHOSTS is only needed if you aren't using the standard >> location ($INFORMIXDIR/etc/sqlhosts) -- that's the same everywhere. >> INFORMIXDIR is only needed if you aren't using the standard location >> -- that too is the same on Unix machines (/usr/informix). >> INFORMIXSERVER is mandatory - period. >> >> > > Thanks for that, I know the basics. But it's ok to provide hints and > directions. I think you're pretty lazy not to provide some kind of > usage instructions right in the installation, > > Do you know the basics? I see no evidence. >> DYLD_LIBRARY_PATH is the analog of SHLIB_PATH or LD_LIBRARY_PATH or >> LIBPATH or ... and does need to be set. Again, there is nothing >> unusual in this. If you can't compile and run ESQL/C programs with >> the environment you have set, you are not going to be able to compile >> the Perl module, which is, when all is said and done, an ESQL/C >> program. >> >> > > You should be able to set the $ENV['whatever'} variable in a typical > program without having to source in an additional shell environment > variable. I want to run programs that are portable and self-contained, > without requiring the user to 'dot in' an environment variable from an > additional shell file. This ain't rocket surgery. > > > Then fix it smart arse >> I suppose it might be possible to detect that the variable isn't set, >> but there are circumstances under which it does not have to be set >> (appropriate settings in /etc/ld.so.conf on Linux, for example). So, >> it is better, from my perspective, to require that people have a >> working Informix environment than to test for things that might not be >> needed. If you want more diagnostics after a failure to test, then >> provide a patch. Do not provide a patch that is interactive; I will >> not accept it. >> >> >>> DBD install variables: >>> >>> export DBI_DBNAME=sysmaster >>> >> I've only ever used that as a last resort - if none of the more >> specific DBD_INFORMIX_* environment variables are set. >> >> >>> export DBD_INFORMIX_DATABASE=sysmaster >>> export DBD_INFORMIX_USERNAME=informix >>> export DBD_INFORMIX_PASSWORD=informix >>> >> There is no way on earth that I am ever going to encourage anyone to >> use either the sysmaster database or the informix user to install >> DBD::Informix. >> >> Absolutely none. >> >> If anything, I would add a proscription from attempting it -- or any >> sys* database. >> >> > > That's pretty gay. The Developer Edition download creates the sysmaster > database by fiat, any other database is optional. After I install IDS > I go and install DBD::Informix, I haven't created any other databases > yet. > > Sorry - I thought you said you know the basics - you need a database so create one. > Maybe you don't know that there is no stores database after the IDS > installation? > > And maybe JL does. > Your install program should go for the least common denominator, > and like I said have a prompt for database, user, and password. Sheesh. > > > >>> Or how about a prompt? 8o/ >>> >> No. >> >> >>> This way it work better since there is no stores database >>> installed with the IDS Developers' Edition. >>> >> It doesn't have to be a stores database -- you get to select the database. >> >> If you read the README file. >> >> > > WEAK. YOU'RE FIRED. Stop by HR and pick up your check. > > And you are on your own now pal. -- Clive

Obnoxio The Clown wrote: > InDeep wrote: >> >> WEAK. YOU'RE FIRED. Stop by HR and pick up your check. > > If you're so fucking smart, how come you couldn't work it out? > I did. But I don't maintain the fucking software do I. I figured it out through the program failing instead of simply prompting me for a fucking database, a fucking user and a fucking password. How gay is that.

InDeep wrote: > Obnoxio The Clown wrote: >> InDeep wrote: >>> WEAK. YOU'RE FIRED. Stop by HR and pick up your check. >> If you're so fucking smart, how come you couldn't work it out? >> > > I did. But I don't maintain the fucking software do I. I figured > it out through the program failing instead of simply prompting me > for a fucking database, a fucking user and a fucking password. How > gay is that. Nearly as gay as your petulant whining. But not quite. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com

Obnoxio The Clown wrote: > InDeep wrote: >> >> As smart as you are, at the level that you are, I am surprised at your >> arrogance and petulance. The user should be considered your goal, not >> how maligned you feel and how annoyed you are about the user actually >> having to actually use your program. How dare they attempt to even >> come to your alter. Kneel before me and beg for your life user! What >> say ye! Speak or die! > > Stop being a cunt. Jonathan gives freely of his time to maintain this, > he deserves your thanks, not your abuse. It's his time, he gets to > decide how to use it, he gets to decide how it works. If you don't like > the way he does it, roll your own and shut the fuck up. > > You moaning, know-nothing, whingeing, ungrateful, arrogant, petulant, > goat-felching twat. > Feel better now? *<8o)

Obnoxio The Clown wrote: > InDeep wrote: >> Obnoxio The Clown wrote: >>> InDeep wrote: >>>> WEAK. YOU'RE FIRED. Stop by HR and pick up your check. >>> If you're so fucking smart, how come you couldn't work it out? >>> >> >> I did. But I don't maintain the fucking software do I. I figured >> it out through the program failing instead of simply prompting me >> for a fucking database, a fucking user and a fucking password. How >> gay is that. > > Nearly as gay as your petulant whining. > > But not quite. > Harsh but fair. *<8o)