Store Brlang command outputs in vars

Certain Brlang commands (such as, for example, #sic-lookup-id) or device commands could be of more use if their output could be stored in a variable to later be used as input for other commands, allowing deckers to build more complex and useful programs. As it stands right now, the only real use for variables is for storing user input.

By Baguette at Aug 25, 2025, 5:24 PM | 1

It's something I may do in the future, but at that point, we're getting into actual programming that requires some real life programming skill to understand, and I'm not sure if that is going to be everyone's cup of tea.

Because you can't stop at just storing output in variables. Because then the only thing you can do with it is log it. And that's the same as the command just outputting the output to the log, which it does now.

We'd need conditionals like if/elseif/else to check the output of the command. And that also means adding a function for 'does this output contain a specific string' so you could do like:

#if
@var contains true
goto blocka
#else
goto blockb
#endif

#blocka
the log was true!
#endblocka
#blockb
the log was false!
#endblockb

And that isn't even very useful, so you'd need the ability for blocks to be more like labels for specific parts of your code you want to run, meaning blocks would have to be able to contain other tags like:

#blocka
#log
the command succeeds!
#endlog
#login
do login stuff
#endlogin
#send-mail
do mails stuff
#endsend-mail
#endblocka

And all that gets difficult to implement (for me) and more and more difficult to understand as a decker.

Just not sure if there will be a big appetite for that. We want people to feel like cool ass deckers, but not actually need to be one IRL.

Time will tell, I'm not against it, but just not sure it is worth it at this point.

(Edited by Slither at 9:18 pm on 9/2/2025)

By Slither at Sep 2, 2025, 9:09 PM | 1

I just want to bump this thread, this would be incredibly useful and streamline a lot of decking.

By BlackSoul at Jul 25, 2026, 2:14 AM | 0

Maybe I don't understand the mechanics well enough, but I don't see a reason you couldn't do something like;

#request-input
Input the target SIC Alias
@sicalias
#endrequest-input
#sic-lookup-id
@sicalias
@lookupresults
#endsic-lookup-id
#some-other-command
@lookupresults
#endsome-other-command

It just takes the results of #sic-lookup-id or #grid-lookup-sic-id and puts that into a variable that is used later in the code.

But even if we DO need conditionals, conditionals aren't very complicated for someone who has no coding knowledge to learn. What is more complicated to learn is things like dicts, and so forth and those "best practices" when it comes the actually coding.

But maybe those commands that function as conditionals, and / or store results as new variables, could have an additional, optional "debugging" argument somehow?

By BlackSoul at Jul 27, 2026, 2:36 AM | 0

Especially important to note, is that the two commands OP suggested are WAY down the UE line, meaning you'd have to have already spent some time in the earlier stages of the skillset before you ever get to conditional commands / commands that store the results as new variables. And since the #variables command and #request-input command are both much earlier, you would already have some familiarity with how variable function first IF you've been creating software already instead of just passively spending UE.

By BlackSoul at Jul 27, 2026, 2:46 AM | 0

-	BlackSoul	3m
-	Crooknose	9s
-	Rillem	57s	Make it personal.
-	zxq	4m	Tools: https://ansicolortool.neocities.org
-	AntiqueBeast	22s
-	SmokePotion	18m	Right or wrong, I'm getting high.
-	Hivemind	7m
-	Terrible_the_duck	1h
-	MrFye	5s
-	fireflies	26s
-	whatislove	1h	reputation is whoever holds a bigger gun
And 22 more hiding and/or disguised

Edit BgBB Icon