use/require only load one file yes of course

What if there are two files named the same in the lib stack.

why does it seem to work sometimes and not others, could it be one loads it from one place and the second loads it from another. If the faulty module existed higher in the lib stack in the failing code then that code would fail, but if in the working code the good module came before the faulty one in the lib stack it would get loaded instead and that code works. That is why i wanted to see where ALL of the manageusers.pm files were located. He may think he has the right lib added to the stack, but it is in the wrong position. But for the faulty code it looks like it only found one copy.

What if there are two files named the same in the lib stack.

Perl tries to load the first file found

$ cat goner1\hi.pm


$ cat goner2\hi.pm
1;

$ perl -Igoner1 -Mhi -e 1
hi.pm did not return a true value.
BEGIN failed--compilation aborted.

$ perl -Igoner2 -Mhi -e 1

$ perl -Igoner1 -Igoner2 -Mhi -e 1
hi.pm did not return a true value.
BEGIN failed--compilation aborted.

$ perl -Igoner1 -Igoner2 -le"print for @INC"
goner1
goner2
...
.
[download]

why does it seem to work sometimes and not others, could it be one loads it from one place and the second loads it from another. If the faulty module existed higher in the lib stack in the failing code then that code would fail, but if in the working code the good module came before the faulty one in the lib stack it would get loaded instead and that code works. That is why i wanted to see where ALL of the manageusers.pm files were located. He may think he has the right lib added to the stack, but it is in the wrong position. But for the faulty code it looks like it only found one copy.

Without trying to be harsh, its simple, all the code resembles spaghetti, its full of red flags

If you remember send windowmessage from cgi back to form that called the cgi, Cookie->fetch problem the story is familiar, OP tries to solve problem by showing fragments of a whole which is beyond understanding, instead of starting with a tiny self contained program that he can understand, debug, and apply what he learned to the big code

For comparison a different guy a few years ago (perl pagination links) same problem (spaghetti but short) , but doesnt take the advice to unblender because its cgi101

Now the situation isn't hopeless, the entire code doesn't have to be thrown out or completely rewritten, the programmer simply has to improve a tiny little bit

tultalk needs to step away from the spaghetti bathtub and begin working with simple plates/bowls, with one single solitary spoonfull of spaghetti, then switch to a second bowl with two spoon fulls of spaghetti, until he can learn his way around the bathtub, because thinking "but bathtub mostly works!" every time he encounters a bug is holding him back

Solution is to start deleting stuff until you've got bare bones, because you can't fix spaghetti by digging in a bathtub of spaghetti, the spaghetti is blocking your view of the spaghetti you're working

The goal is to gain/learn a clear mental picture of the overview/birds eye view of the code, how cgi operates, how every single component works and fits together, and the only way to do that is to start simple, a new file for every feature/addition/subroutine...

The problem is the OP keeps pointing back at the huge bathtub and saying I made that it mostly works just help me fix it, but

You skip understanding 1/10 parts that make up the bathtub, and then fix a problem caused by 5 different pieces of code in 5 different files, 4 of which shouldn't touch $global_variable, that shouldn't even be global ...

But the guy is trying and thats good, just has to try something that has a chance of working

If this was face to face meeting the current warning/error would have been sorted by Re^2 ... but the OP would still keep pointing at the bathtub unless there was someone to make him go through the motions to improve

The reason i wanted to see if there was more than one copy in the lib stack was because he said it didnt work sometimes, but then when he tried the shorter examples those times it did work. Yes maybe i gave him too much credit in assuming he was loading the newest version into the lib stack at all. But it seemed more likely to me that there were now two versions and they were in different places.

You should go back to the "beginning", his problems with Switch( Switch.pm Failure). It was some of the strangest code ive seen, with a strange subroutine wrapped around the switch call, and returns sprinkled all over. It was the strangeness that intrigued me, and when i figured it out (Re^4: Switch.pm Failure ( CGI::Switch? )) all the artifacts made sense, why the brackets after Switch, why the sub wrapper, and why the returns. SO i have been aware of what kind of code we are talking about since the beginning. I am also aware of his other faults you also have mentioned, which is one reason i have not participated with him of late. But then i thought that maybe he thought he was updating the code in the tree, but it was in the wrong place, so the old code being higher in the lib stack was getting loaded even though he had updated the new code in a lower dir. And when he hand tested the simpler test code the lib stack was different. It was an idea it seems that poj also had. So i asked him to add the full lib search to see if there were two copies of manageusers in the stack.

after all this time he isnt going to change, he may whine that people are being mean to him and he knows what he is doing, but nothing changes.