Use of Variables inside Aliases

[Xavi_8m]

Hello there, new user here!

I've gotta say that I am having an absolute blast fiddling around with Find And Run Robot. I adore how amazingly powerful it can be with a footprint of 3MBytes. I'm also digging big time that it's not "indexed", minimizing the footprint even further. I'm most definitely gonna start using it as my main launcher, waving goodbye to heavier alternatives.

Now I'll cut to the chase: I'm having an issue while attempting to use variables inside Aliases, and I was hoping someone could lend me a hand.

First of all, I'll say that I have a programming background, and I've read the Alias and Variables Help pages thoroughly, so I am aware of how variables are to be used (at least at a basic level). For example, I know that if a variable is defined as:

[Select]

[myVar]
hundred=100

Then, said variable can be accessed via %uservar.myvar.hundred% from inside the Alias. I've created a test alias to illustrate how this would work. Here's the test configuration:

Fig1. Setup of an Alias that uses a raw variable

And here's how the test triggers the variable:

Fig2. Using the previous Alias. Please, note that the "hundred" string is actually
not necessary, it could've been any other string (or even empty)

So far so good. No issues here. My problem comes when I want to use a regular expression captured group to access a variable name. Here's where things get dirty:

Fig3. Setup of an Alias that uses a regex capture group as a variable

And here's where the problem that appears:the Alias does not seem to resolve the variable name (uservar.myvar.$$1) properly. When I try to use the alias from the launcher I get this error message of sorts:

Fig4. Using the regex'd Alias

My question being.... why is this not working!?!?!?!?!?

I am pretty sure that I know what the problem is in here: most likely, the Alias parser is looking for actual variable uservar.myvar.$$1, with the dollar symbols and all, which of course does not exist. But then comes the UI print function, which does indeed resolve the $$1 into "hundred" and thus spits the error message we see in Figure 4:

[Select]

MISSINGUSERVAR:myvar.hundred

I'm gonna guess that I'm asking too deep of a question, but I'll cross my fingers and hope for an available quick fix for this issue. Maybe using 3 dollar symbols instead of 2? Putting it upside down and shaking it? 

Thank you very much for such an amazing piece of software, and I'll see you around,
Cheers.

[Nod5]

I don't know of any workaround to do exactly what you want to do. But perhaps mouser does.

Anyway I like that you're new to FARR but already push the boundaries Aliases are powerful so maybe there is is some other way to achieve the end goal you're after. Could you tell more about the use case?

[Xavi_8m]

Could you tell more about the use case?

-Nod5 (April 26, 2019, 04:29 PM)

Surely. What I am after is a simple UserName <--> UserID mapping when querying a URL.

Allow me to illustrate it with a practical example. Say, for example, that I own a webpage and every new user gets a numeric ID. After four new users have registered you end up with a UserName <--> UserID map like this one:

[Select]

Alice is User 001
Bob is user 002
Carl is user 003
Daniel is user 004

Now, say that this webpage of mine allows you to access the user profile pages through an URL such as:

[Select]

www.mypage.com/user/USERID

Where USERID is the number assigned to each user. So, if you wanted to access Daniel's profile you'd visit the following URL:

[Select]

www.mypage.com/user/004

But in your day-to-day life you ain't gonna remember that Daniel is user "004", you will remember Daniel as Daniel!!! So what I want to do is to create a macro of sorts that takes in the real name of the user:

[Select]

mykeyword Daniel

and then maps the user's name to the respective user ID, and builds the URL:

[Select]

www.mypage.com/user/004

That's where my original post comes in. My idea around this issue would be to create a set of variables such as:

[Select]

[myusers]
Alice=001
Bob=002
Carl=003
Daniel=004

... and then I'd use a regular expression to capture the first parameter, which would then be fed to the following alias:

[Select]

www.mypage.com/user/%uservar.myusers.$$1%

That'd be it!
To be completely honest I haven't given too much thought to the issue. Maybe the optimal solution doesn't use Aliases, or maybe I am overthinking the problem a little too hard. It just felt natural to me using a regular expression as a variable name (that is, abusing/assuming reflection). So I tried... and failed 

[mouser]

Hi Xavi_8m, and welcome to the site 

I'm glad you are liking FARR -- you sure jumped right into the advanced stuff
I think I should be able to fix your problem -- sounds like it's just a matter of the order that FARR replaces variables and regex values, and that regex $$n values should be resolved first.

[mouser]

There are also alternative ways to do what you want, that might be less advanced but easier to maintain.
For example, FARR is very happy to let you make lists of items, either in an alias or even in a separate file, and then filter based on them.

So if you make an alias called "users" that just had a list of your users and their associated web urls like:

Code: Text [Select]

1. alice | http://www.mypage.com/user/1
2. bob | http://www.mypage.com/user/2
3. etc.

The advantage of doing it that "simpler" way is that you could type "users" and see a list of all your user urls, and then type "users b" to have it start filtering only users starting with b, or just type "users bob" and hit enter without thinking.  This also has the advantage of being less sensitive to spelling errors and helping you remember user names, etc.

There may be cases where using complex variables and regular expressions make sense, but it may be that sometimes just using a simple list of labeled results is cleaner.  You could also put that list in a text file and tell farr alias to grab the list from the text file so you could more easily update it outside of farr..

[Nod5]

Just to add to mouser's suggestion:
You can use the list approach together with RegEx and RegEx result filter to ensure that only the list items are shown in results, and filtered as you type. Without RegEx unwanted files that contain the keyword string might also show up in the results.

Example of what I mean with RegEx result filter:


With the above you'd type "gg" to get the whole list and nothing else. Then keep typing to filter the list.

[Xavi_8m]

Excellent! Thanks a lot for the support.

The suggested use of a Filtered Alias list is indeed the better option: more dynamic and easier to maintain than a list of variables. Still I wish I could use variables inside aliases!

Cheers.

[Nod5]

I think I should be able to fix your problem -- sounds like it's just a matter of the order that FARR replaces variables and regex values, and that regex $$n values should be resolved first.

-mouser (April 26, 2019, 06:13 PM)

Consider adding a list with the resolving order to the helpfile after the changes. Things that might resolve in some order or other:  %uservar.myvar.hundred% variables, $$1 regex matches, the new fileresults command, the older #filecontents command.

Helpfile says that #filecontents can be used recursively (haven't tried it) so FARR already resolves at least the string "#filecontents" for that command. But does/should #filecontents and fileresults commands also resolve %uservar.myvar.hundred% and $$1 in the file contents and if yes in what order?

Hypothetical, overly complex edge case example
- User types input that triggers a FARR alias with RegEx that puts the string "file" in $$1 and "cool" in $$2
- The alias has this results line:

[Select]

fileresults C:\folder\%uservar.myvar.$$1%.txt

- with the suggested change in this thread that line would first resolve to

[Select]

fileresults C:\folder\%uservar.myvar.file%.txt

- imagine the variable %uservar.myvar.file% contains string "testingfile", we then get

[Select]

fileresults C:\folder\testingfile.txt

- imagine that file contains:

[Select]

#$$1contents C:\folder\results.txt

- which, if command fileresults resolves $$1, will resolve to the command

[Select]

#filecontents C:\folder\results.txt

- imagine that file in turn contains

[Select]

C:\here\%uservar.othervar.$$2%.txt

- which, again if command #filecontents also resolves $$1 and % variables, resolves to

[Select]

C:\here\%uservar.othervar.cool%.txt

- which, imagine, resolves to

[Select]

C:\here\final_file.txt

- which contains

Spoiler

Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[mouser]

Yes, I should provide a list of order of resolution.  Even smarter might be to have FARR resolve what it can, and defer resolving those that it can't if they might be expanded by another.
Spoiler ha !