Thank you.
I would have taken all your inputs had I been designing new stuff.
But, this is existing stuff and cant be redesigned or changed.
I am looking for this change to avoid having to modify some 200 files all
setting the same environment variable.
If this does not work(locking and not letting others change the hash key
value), I will have to do the old way of having to modify all the 200 files
that are setting this variable and comment out that code.


On 12 May 2014 15:39, Janek Schleicher wrote:

On 12.05.2014 11:39, Satya Prasad Nemana wrote:

But the solution will not suffice.
As I said, there are various other functions in different packages which
are modifying an environment variable.
I want to have a lock or make it ready only so that only one can modify
and the rest cant.
This code will work but I have to make the same code change in all the
places where this hash value is being set.
so, this will not work for me.
Some general stuff:

- having various other functions in different packages modifying and
working with global variables is usually not a good idea. With growing
complexity, your code will be hard to handle and to understand and
controlling the workflow gets nasty. You're probably right at the moment
exactly at this point.

- Trying to modify environment variables to control workflow is a bad idea
in general. There a gazillions possible that side effects are not handlebar
and even if it gets too complicated.

- Bulding a global data structure around environment variables (like you
try by locking them via Perl) will not work or not work like you expect
unless the underlying OS enhances it. For at least, *nix und Windows does
not. Usually the environment variables are controlled by the OS and not the
programming language. Yes, you can set $ENV{...} and it will work, but
don't do it for program flow. Do it for configuration.

- In general, if you want to encapsulate a data structure, so only your
own script/module/whatever can change it allover and the rest of the world
only should get restricted access, the solution is called: Object Oriented
Programming. [Here, maybe you want a Singleton-Object that controlls a
global configuration?]

Please tell me if there are other ways to handle this.
2 general ways are there:

- Make your scripts/modules/programs/w/e indepedent from each other. So
they get data piped in and pipe it out. They can use then environment
variables, but they use it for configuration, not for working flow logic.
Then in the end, all your master program will do is similiar to a shell
script. Like a ps -a | grep -r *.txt | ... and so on.

- Redesign it object oriented.

If your code is small, let's say <500 lines, then of course you can find
"hacking" alternatives, but even if you intend it, first describe your
problem detailed and analyzed.
Especially: Why do you want global locked name=>key pairs?
As you haven't yet (all you say so far is that you want them), neither you
nor we can give you a way to the solution.


Satya Prasad

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 7 | next ›
Discussion Overview
groupbeginners @
postedMay 12, '14 at 8:59a
activeMay 13, '14 at 3:51p



site design / logo © 2021 Grokbase