topic Re: Parsing a variable to a lookup command in Splunk Search

Parsing a variable to a lookup command

maigaard — Tue, 12 Aug 2025 13:09:51 GMT

Dear Splunk gurus

I am trying to get the lookup command to accept the lookup table name from a variable.

Example:

| eval list2=case(like(llist, "%option1%"), "list_number_1", like(risklist, "%option2%"), "list_number_2")
| lookup list2 Name AS value

So... I successfully get the right lookup name. If I table out the list2 (|table list2), I can see that list2 equals the name of the right lookup ("list_number_1"). So the eval command works as intended.

If I use "|lookup list_number_1 Name AS value" it works great.
So the lookup command works as intended.

But if I use "|lookup list2 Name AS value" it does not work even though "list2" = "list_number_1".

So it seems the lookup command will not accept a variable even when the variable contains the name of a valid lookup file.

But can that be true? This works everywhere else in Splunk...

Re: Parsing a variable to a lookup command

ITWhisperer — Tue, 12 Aug 2025 13:37:08 GMT

Please can you give examples of what "this" is as in "This works everywhere else in Splunk"?

Having said that, if this is for use in a dashboard, you may be able to achieve your desired outcome with the use of tokens.

Re: Parsing a variable to a lookup command

maigaard — Tue, 12 Aug 2025 14:31:12 GMT

What I mean by "this works everywhere else" is that the use of variables as input works elsewhere.

This is not for a dashboard, but is meant to be used in a saved search.

Re: Parsing a variable to a lookup command

bowesmana — Wed, 13 Aug 2025 03:09:55 GMT

The use of variables does not work everywhere, but you can achieve this with a subsearch. If you wrap the eval statement as a subsearch to the lookup command it will work, i.e.

| lookup [ | makeresults | eval list2=case(like(llist, "%option1%"), "list_number_1", like(risklist, "%option2%"), "list_number_2") | return $list2 ] Name as value

Re: Parsing a variable to a lookup command

PickleRick — Wed, 13 Aug 2025 06:00:15 GMT

No. It doesn't "work everywhere". Some commands support field names as arguments, some don't - they need static values. Additionally dashboards support substituting tokens for values in SPL search but this is done by the dashboard mechanism _before_ the resulting search is spawned so the tokens are being substituted with actual values from the dashboard before the SPL is sent for execution.

To some extent you can sometimes do "dynamic programming" by generating part of your SPL with a subsearch as @bowesmana showed or by using the map command (which is hardly ever the right solution) but most often it's just a case of rethinking your problem.

What is it you want to achieve? If you want to decide dynamically _per event_ which lookup to look up from, that will not work. Splunk doesn't do that. Running a subsearch-based lookup name assignment would yield just one lookup for your whole search.

The right technique here would be to run two lookups sequentially, populating two separate (sets of) fields and then in a subsequent eval assign dynamically the destination field to either of resulting values depending on your logical conditons.