Bug - Not A Bug get_path() & friends

StDoodle

Minion
I was doing an ashref search for something completely unrelated, when I saw a few ash functions I was unfamiliar with: get_path(), get_path_full(), and get_path_variables().

Of course I HAD to try them out... get_path_full() returned an empty string; get_path() and get_path_variables() both caused an error.

Debug log enclosed. Note that I have no idea if these functions are supposed to be exposed or not; if not, then of course removing them from user view & access is completely understandable as the solution.
 

Attachments

  • DEBUG_20101029.txt
    4.2 KB · Views: 53

Theraze

Active member
They exist for relay scripts... they return the page the script currently has loaded. However, when you run them from the gCLI, you don't have a page, hence the error...
 

Grotfang

Developer
That's still bad behaviour, no matter why it came about.

Unfortunately, I'm struggling to replicate the problem. StDoodle, were you logged in when you tried these functions out?
 

StDoodle

Minion
Yup, I was logged in. Tried them from CLI directly at the time of that bug report. Also tried them later from a rely_ script and got the script name for the first 2 and nothing for the last (but no debug). Though I imagine they're intended for relay overrides. (Was in-run, so didn't test that.)
 

Theraze

Active member
Nothing is what's expected for the last on most pages... the get_path() returns the stripped page (everything before ?), get_path_full() returns the full page (everything including before/after ?), and get_path_variables() returns just the variables if there are any (only what's past ?, if there is anything).

I had these non-erroring, but it's possible that during a cleanup the way it was protected from the error got screwed up again.
 

StDoodle

Minion
Now that I know what they're for, it looks like they could be very useful in some situations for the macro-building consult script(s) I'm working on (say, whenever building a macro past the first in the fight, if you need a quick check of what the previous macro had). Thanks!
 

Theraze

Active member
Not a problem. That's actually the point of the variables one... if you need to figure out exactly what got passed to the last page and already have an expectation of which page it should be, it should let you know what those are. All of them call the active relayrequest... problem is when you don't have one, which I think was the reason why I spawned a new request originally before I 'cleaned' it again and put it calling the existing one (or not).
 

Bale

Minion
Now that I know what they're for, it looks like they could be very useful in some situations for the macro-building consult script(s) I'm working on (say, whenever building a macro past the first in the fight, if you need a quick check of what the previous macro had). Thanks!

If your script needs to know the previous macro, then it should have simply saved that information to a string variable. ;)
 

StDoodle

Minion
Bah, you crazy people and your "logic" and your "simpler methods." :p Still, I could see this being useful for other relay overrides that are rolling around in the back of my mind...
 

heeheehee

Developer
Staff member
I'd imagine only for master relay overrides, really, since we've had the form_field() and form_fields() functions for some time.
 
Top