Re: Problems with CGI script behaviour

If there are "1M reasons why you can't use a template," and "1M reasons why you can't use CGI," what is there to say? How are we supposed to help you debug this? You are building a complex thing that is one-of-a-kind by your choice, and then one day you will move on and there will be no one in the world to maintain it. Your successor will scrap it all and start again.

Comment on Re: Problems with CGI script behaviour

Replies are listed 'Best First'.
Re^2: Problems with CGI script behaviour by SerZKO (Beadle) on Aug 01, 2012 at 14:33 UTC
Well, I didn't mean to be boring, but if you want to know the reasons, here comes the representative example: 1. This is machine we call "BlackBox" which means it was installed and it's been taken care of by our service partner. If we add/change/delete things that come with it (preinstalled of course) that are not covered in service agreement, we loose support. For example - there's neither mySQL nor postgreSQL installed on that machine, and will never be installed (that's the agreement). 2. Vendor of that "blackbox" is a huge multinational company that probably would eat (both our service partner and us) us if we change something they set up. 3. We don't have access rights to e.g. make and install own perl distribution. That basically means that we can use everything that is installed, but install/upgrade/add/change/delete without service partner agrees is strictly forbidden (according to SLA). Now, we can and would like to use some things that already are installed (file with data, Perl distribution, etc.), but those are restrictions which I described as 1M reasons. I saw this as a challenge (although I'm not a programmer at all, even if my job requires a lot of C and shell scripting knowledge) and didn't mean to offend anyone...	[reply]

Replies are listed 'Best First'.

Re^2: Problems with CGI script behaviour
by SerZKO (Beadle) on Aug 01, 2012 at 14:33 UTC

Well, I didn't mean to be boring, but if you want to know the reasons, here comes the representative example:

1. This is machine we call "BlackBox" which means it was installed and it's been taken care of by our service partner. If we add/change/delete things that come with it (preinstalled of course) that are not covered in service agreement, we loose support. For example - there's neither mySQL nor postgreSQL installed on that machine, and will never be installed (that's the agreement).

2. Vendor of that "blackbox" is a huge multinational company that probably would eat (both our service partner and us) us if we change something they set up.

3. We don't have access rights to e.g. make and install own perl distribution.

That basically means that we can use everything that is installed, but install/upgrade/add/change/delete without service partner agrees is strictly forbidden (according to SLA). Now, we can and would like to use some things that already are installed (file with data, Perl distribution, etc.), but those are restrictions which I described as 1M reasons. I saw this as a challenge (although I'm not a programmer at all, even if my job requires a lot of C and shell scripting knowledge) and didn't mean to offend anyone...

[reply]