How do I keep ASH scripts from outputting to the CLI?

[Fluxxdog]

I love >>/dev/null It's a sassy way of keeping information you don't need from popping up. But that's another story, another time.

One script I'm running can potentially spit out a LOT of data to the CLI, quite needlessly at that. set_property() will display "property => blahblahblahblah" and if the blahs are long, it can take up quite a bit of room.

Is there any way to keep set_property() from putting out any output? I know speculate has a quiet command, but it's the only thing I've seen like that.

 

[StDoodle]

As much as it would sometimes be nice to have "cleaner" execution of scripts, changing properties can have a HUGE impact on one's use of KoLmafia, so I'm not all that comfortable with a script being able to change them without alerting the user. But this may not be the consensus.

 

[coaster3000]

As much as it would sometimes be nice to have "cleaner" execution of scripts, changing properties can have a HUGE impact on one's use of KoLmafia, so I'm not all that comfortable with a script being able to change them without alerting the user. But this may not be the consensus.

I agree i would never like a script to change settings without user check.

 

[Fluxxdog]

I see the issue. And on the flip side, if the user is never looking at the CLI, it's not important anyway. Eh, I just get over it.

 

[Winterbay]

I see the issue. And on the flip side, if the user is never looking at the CLI, it's not important anyway. Eh, I just get over it.

Well, apart from potentially filling up the session log and thus the drive it is stored on. Probably a small problem though

 

[Theraze]

If you're setting enough properties that it'll fill up the whole drive with a script, then I at least would want to know what's getting set that poorly, since that level of setting would be doing horrors to your CPU cycles...

 

[Fluxxdog]

Heh, it's either a bunch of different properties or one property getting appended to multiple times.

set_property("propname",get_property("propname")+newdata)

What I'm using it for is meant to be added on to once in a while, but when you first start it up, it gets very messy as it can be adding up to 50 things at once. Shouldn't be filling a whole drive though.

 

[StDoodle]

Unless you need to set once-per-day properties, I highly recommend using zlib. 9 times out of 10 it's a much easier & cleaner solution vs. setting custom properties. And if you're doing that for built-in properties... well, that should be rare, at the least.

 

[Fluxxdog]

I use zlib quite a bit, but zlib is not intended to update settings from within scripts while they're running. Thanks though ^^

 

[slyz]

Why not? You can find all of your Zlib settings in the vars map, changing a setting is as simple as

vars["setting"] = "value";

You can simply use updatevars() to save everything to your vars file.

 

[fronobulax]

Why not? You can find all of your Zlib settings in the vars map, changing a setting is as simple as

vars["setting"] = "value";

Will that play nicely with the normalization work zarqon is doing? The approach also violates good encapsulation practices although I fully agree that it is pretty fussy to apply those to ASH scripts.

 

[slyz]

vars is still a string [ string ] map (for now at least, but I don't see how this could be different, I hope Z will surprise us!). normalize() is mostly aesthetic for now, since when a script needs to use a zlib var, you still need to transform it from a string to what you want, like this for example:

familiar zlib_fam = vars[ "setting" ].to_familiar() ;

Of course, in the example in my other post, the setting was already turned into a string, but you would need to use to_string() somwhere, if that is what you meant.

I didn't quite understand what you mean by encapsulation practices in this case though. Do you mean scripts should change zlib vars by doing:

cli_execute( "zlib setting = value" );

I don't think that would work since the vars map that was loaded in the current instance of the script wouldn't be changed. I'll try to test this when I have some time.

 

[Fluxxdog]

I know, and I believe Zarqon has a pretty good reason for not mentioning that you can change the entire vars_file while running a script. Not just the map, but the text file that vars reads from. Unless he tells different... Dunno what his take on that approach is.

Edit: Slyz, I like that approach more than using updatevars(). I'll give it a test run myself too.
Edit2:

void adjustvars(string varsname, string varsvalue){
	vars[varsname] = varsvalue; updatevars();}

You're right if I used the cli_execute method, they would be out of sync. I had made this before and not used it because of the issue I had above. I'll get over myself. What's more, updatevars() uses vprint. That would address my display concern. And with it modeled after set_property, it's easier to implement.