in reply to Why forced to do the job the hard way?
in thread A Hashing Question

I agree that if you don't stand up your rights, whatever rights they are, then you will not get the tools you need.

What I don't understand, is how a person can be in a position where they can upload a script, but yet can't install modules in the same dir as the script?

But, why would you want to run perl on NT anyway?

The Book of Larry says: Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as "Unix".
-- Larry Wall in <1994Apr6.184419.3687@netlabs.com> 

Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
  • Comment on RE: Why forced to do the job the hard way?

Replies are listed 'Best First'.
RE: RE: Why forced to do the job the hard way?
by BigJoe (Curate) on Jun 17, 2000 at 02:33 UTC
    In my case, our IS department doesn't trust us accessing the Web server. We have to have a working model of our scripts on sim server first. Then they test it and move the script to their server.

    I would love a job where I could program PERL on a Linux system. But I don't have the experience to get hired for it yet. So when the company that I work for asked for this I offered to get experience for my resume to get one of those great jobs.

    --BigJoe
[reply]
      But Storable works fine with ActiveState perl! We're not asking you to wait for Linux. We're just saying, use Storable even on AS.

      -- Randal L. Schwartz, Perl hacker

[reply]

      If they don't trust you, why the heck did they hire you? Anyhow, they could have a policy of testing your scripts on a non-production server before moving them to the productions server. I do that even if I have root, and that method means I don't have to "trust" anybody... I can just test the script, and copy it over when I'm happy with it.

      I don't see how having access to the server and wanting to test the scripts before they go production are related things.

      Ozymandias: You are certainly correct, I only accept projects where I am in charge of IS, I wouldn't even consider working in it. But I won't work with people I'm not willing to trust.

      Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
[reply]
        Thereby proving you've never worked in IS.

        The #1 rule in IS is "trust no one", particularly if it's a production system. The right way to do it is to develop on one system, test on a second, production is a third. Developers move freely between development and test. Test is kept as similar to the production system as possible. Only senior IS people - often only two admins per box, and one of those is just a backup - actually have access to move things from test to production. Anything less is too risky.

        The correct solution to the problem is to have IS install the needed module on the production system. They SHOULD do that, if you can show that it's necessary and safe.

        - Ozymandias

[reply]
        I work in a company of over 2000 users and the IS dept can't really assess each person. (I got put in a Tech support dept by a Consulting place, But that is another story).

        --Joe
[reply]

In Section Seekers of Perl Wisdom