On Sat, 19 Jun 2021, Sven Schreiber wrote: > </hansl> > > This could be generalized, but the whole thing strikes me as relatively > complicated. I have the feeling we discussed this before, but I don't > remember any details. What's the best way to query the currently active > set options programmatically? ? set shell_ok shell_ok: boolean (on/off), currently on

But that's not programmatic of course. You do have the --to-file option to "set". And I suppose we could offer a bundle of all set variables as, say, $settings.

On Sat, 19 Jun 2021, Allin Cottrell wrote: > ? set shell_ok > shell_ok: boolean (on/off), currently on > > But that's not programmatic of course. You do have the --to-file > option to "set". And I suppose we could offer a bundle of all set > variables as, say, $settings. This would be quite nice. Or we could add a key to $sysinfo.

Am 20.06.2021 um 12:08 schrieb Artur T.: > Am 19.06.21 um 20:40 schrieb Riccardo (Jack) Lucchetti: >> On Sat, 19 Jun 2021, Allin Cottrell wrote: >> >>> ? set shell_ok >>> shell_ok: boolean (on/off), currently on >>> >>> But that's not programmatic of course. You do have the --to-file >>> option to "set". And I suppose we could offer a bundle of all set >>> variables as, say, $settings. >> >> This would be quite nice. Or we could add a key to $sysinfo. > > Yes, that's also useful and would avoid having another accessor. I don't think $sysinfo is suitable, because it collects static information about the host machine and the gretl build. In contrast, the settings are dynamic.

Am 20.06.2021 um 12:40 schrieb Riccardo (Jack) Lucchetti: > On Sun, 20 Jun 2021, Sven Schreiber wrote: >>>> This would be quite nice. Or we could add a key to $sysinfo. >>> >>> Yes, that's also useful and would avoid having another accessor. >> >> I don't think $sysinfo is suitable, because it collects static >> information about the host machine and the gretl build. In contrast, the >> settings are dynamic. > > Well, to be pedantic I should have to point out that we now have > $sysinfo.mem, which is (partly) dynamic.

I don't know what that is, it must be new. Perhpas it's even not a good idea to put it in sysinfo when it's dynamic? In any case, I think the term 'sysinfo' starts to be misleading if the 'set' output goes in there, it has nothing to do with the host system. '$info' might be an encompassing term.

Am 20.06.21 um 12:40 schrieb Riccardo (Jack) Lucchetti: > On Sun, 20 Jun 2021, Sven Schreiber wrote: > >> Am 20.06.2021 um 12:08 schrieb Artur T.: >>> Am 19.06.21 um 20:40 schrieb Riccardo (Jack) Lucchetti: >>>> On Sat, 19 Jun 2021, Allin Cottrell wrote: >>>> >>>>> ? set shell_ok >>>>> shell_ok: boolean (on/off), currently on >>>>> >>>>> But that's not programmatic of course. You do have the --to-file >>>>> option to "set". And I suppose we could offer a bundle of all set >>>>> variables as, say, $settings. >>>> >>>> This would be quite nice. Or we could add a key to $sysinfo. >>> >>> Yes, that's also useful and would avoid having another accessor. >> >> I don't think $sysinfo is suitable, because it collects static >> information about the host machine and the gretl build. In contrast, the >> settings are dynamic. > > Well, to be pedantic I should have to point out that we now have > $sysinfo.mem, which is (partly) dynamic. I think the distinction should not between static vs. dynamic information but rather reflect the purpose of an accessor. And re-thinking Sven's argument, it looks to me that retrieving system information ($sysinfo) is different from getting user-settings ($settings).