in reply to Re^13: global var
in thread global var
two days ago and one day ago both answer this
Now regarding Re^13: global var this is the output of your posted bug report
$ perl -I. tultalk 428
It shows no bug , no problem , no errors, no warnings
The code you posted doesn't reproduce the problem you want to solve in your real program
If your real program were the same, then it should have no problem
But then you say your real program does have a problem
This is not productive way to solve problems
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^15: global var
by tultalk (Monk) on Apr 11, 2017 at 14:23 UTC | |
You pose a dilemma here. Short and sweet, no error. This part of code shows 0 or undefiend at <-------------------------------
The other side of the interface boundary:
Exports the variable $LoggedOn_user_id The error reported is that $LoggedOn_user_id is not exported by manageusrs. The short test program does not display that error. In my program on the defining side of the interface boundary, I declare our $LoggedOn_user_id = 0; so there clearly should be something to export. And later I populate the variable with the desired data
And at that point, the desired information is in the variable. | [reply] [d/l] [select] |
by huck (Prior) on Apr 11, 2017 at 15:23 UTC | |
IN the code that does show that $LoggedOn_user_id is not exported by manageusrs. put this in right after your use manageusers qw($LoggedOn_user_id); statement and see what your error log says. Be careful to cut and past all of that code, right click on download and select save file as and cut it all from that file you downloaded. Then do it in your sample program above too, and compare the warnings you get from both, remember order in the error log matters! Cut and paste the warnings from both the sample and the real program back here. and saying And later I populate the variable with the desired data is easy, proving it is not as easy. So cut and paste ALL of manageusers::OpenConnection() and ALL of every subroutine it calls to prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else. | [reply] [d/l] [select] |
by tultalk (Monk) on Apr 11, 2017 at 18:09 UTC | |
Test Program Error Log
Real Program Error log: found:/home/jalamior/www/httpsdocs/cgi-bin/lib/perl/manageusers.pm at update_tables-development.cgi line 41. Tue Apr 11 11:26:22 2017 update_tables-development.cgi: found:/home/jalamior/www/httpsdocs/cgi-bin/lib/perl/manageusers.pm at update_tables-development.cgi line 41. Can't opendir /usr/local/apache/lib/perl: No such file or directory at update_tables-development.cgi line 38. Tue Apr 11 11:26:22 2017 update_tables-development.cgi: Can't opendir /usr/local/apache/lib/perl: No such file or directory at update_tables-development.cgi line 38.
You say: and saying And later I populate the variable with the desired data is easy, proving it is not as easy. So cut and paste ALL of manageusers::OpenConnection() and ALL of every subroutine it calls to prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else. I don't understand the question. Search all fdiles on manageusers::OpenConnection(); yields 10 hits.
They all call the same function
You say: prove that you do set $manageusers::LoggedOn_user_id properly every time and dont set it back to zero somewhere else It is oly populated at two places. For a new logged on user it gets the id from the session table. For an already logged on user (cookie expires 7 days) it get the ID from the session table based on the SID lookup.
| [reply] [d/l] [select] |
by huck (Prior) on Apr 11, 2017 at 18:33 UTC | |
by tultalk (Monk) on Apr 11, 2017 at 20:14 UTC | |
| |
by Anonymous Monk on Apr 11, 2017 at 21:16 UTC | |
This is how you write that shorter and better
| [reply] [d/l] |
by huck (Prior) on Apr 11, 2017 at 21:51 UTC | |
by Anonymous Monk on Apr 11, 2017 at 22:33 UTC | |
| |
by Anonymous Monk on Apr 11, 2017 at 22:07 UTC | |
This part of code shows 0 or undefiend at ... No it doesnt This is the same as before, you post a fragment of code that does not compile, does not run, does not show the problem Maybe it shows the problem on your machine, where the code is complete and compiles and runs, but over here on my machine it shows that you posted incomplete code which cannot help you fix your problem huck guesses that you're loading the wrong .pm file but thats too generous on his part The problem is you dont want to do what is required to solve the problem, which is keep deleting parts of code which have nothing to do with the problem, until you're left with a short piece of code which does reproduce the problem But you keep posting fragments and hoping that will help you solve it Thats a weird way to ask for help, here is a joke for that Q: I'm hungry but there is no food in the refrigerator?
| [reply] |