Re: [lmi] --gui_test_path and implicitly created output files

[Greg Chicares]

On 2014-12-14 17:55, Vadim Zeitlin wrote:
> On Sun, 14 Dec 2014 15:58:33 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Some lmi output files are created...in the directory where the program 
> happens
> GC> to be run, I suppose: the 'monthly_trace' and '.mec.tsv' files, for 
> instance.
> GC> These and quite a few others are created as deliberate side effects. Let's
> GC> first address the theoretical question where they should be created: I 
> guess
> GC> the FHS would prefer /var/opt/lmi/ . Is it worth changing lmi to do that?
> 
>  It definitely would be if/when lmi were to be usable under Unix systems as
> /opt/lmi/bin wouldn't typically be writable at all.

Okay, someday. I'll mark this read for now; I'll remember it when it comes
time to cross that bridge. So far, I'm still trying to cope with things like:

- try different gnome themes...oops, system default colors became black on
black, and that's why a terminal doesn't seem usable

- give root pw just to 'reboot'? Nonsense...just run visudo; oops, that's
not vi, it's pico or something like that--but it's always fun (NOT) to
learn a new editor.

- it's apparently really hard to get 960x600 with an exceedingly rare
nvidia card...but I've found a method that might work....

Once I'm past all that, I'll work on kvm, so I can run msw as a guest
and (I hope) never have to boot it again--and then test all the stuff
I normally do for work, ultimately getting lmi to work in a guest OS in
  C:\opt\lmi\bin
Someday I'll return to the /opt/lmi/bin question, but not this year.

> And even under Windows,
> theoretically speaking, these files are user-specific (as the files being
> opened are opened by some specific user), so the output files should be
> generated in a user-specific location as well, e.g. something like
> wxStandardPaths::GetUserLocalDataDir() (see
> http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#a456fcd2e246c57a61dda9511e4dac9c3)
> 
>  But this is definitely more theoretical than practical consideration,
> especially if no users have been ever bothered by this.

They've migrated to msw-7, and still no one has ever been bothered by
this. There must be millions of msw programs that rely on the ability to
write files in the directory where the binary resides, and msw wouldn't
break that.