OpenEuphoria

Re: Opening a file - File Open Dialog spoils future code

• Posted by CChris <christian.cuvier at agr?cult?re.gouv.fr> Jan 16, 2008
• 517 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > All right, I should have checked first, but the bottom line is the same:
> > never use current_dir() under Windows. Here is what I found on MSDN:
> > <quote>
> > The directory at the end of the active path is called the current
> > directory; it is the directory in which the active application started,
> > unless explicitly changed. An application can determine which directory
> > is current by calling the GetCurrentDirectory function.
> > 
> > An application can change the current directory by calling the
> > SetCurrentDirectory function.
> > </quote>
> 
> I don't see how your conclusion follows from this.  Perhaps we could/should
> alter the behavior of the interpreter under windows to call the win32
> functions instead of the c library.
> 
> > I have recently wondered why I wasn't finding ex.err after a program crash.
> > Searching ex.err on my machine reported 9 different directories, some of
> > which I'd havd never thought about. Since ex.err is created using
> > open("ex.err","w"), I consider the "current directory" to be undefined for
> > practical use: it is defined, but as something volatile (what is the active
> > application on a multiprocess platform?). I'd go as far as recommending to
> > drop support of current_dir() and chdir() under Windows.
> 
> I think you've misunderstood what MSDN was saying.  You can change the current
> dir for your app, not for the system.  It's only volatile in that you can
> change it.  It shouldn't change based on other processes.
> 
> I have been annoyed at times by where ex.err is created.  Perhaps that's
> another enhancement to be considered.  But I don't think that it means that
> we should abandon current_dir/chdir.
> 
> Matt

I am only saying two things:
1/ since ex.err may land in folders from where no Eu rogram was ever run, other
processes must interfere in some cases (in case of a crash? I don't know);
2/ since use of the current directory is so confusing for practical use under
Windows, and since there is such an excessive concern about avoiding confuion in
the language, I think relying on what the "current directory" happens to be in an
only mildly deterministic way (from the user standpoint) should be actively
discouraged in some way.

To reply to Pete's post: I don't think this would be win32lib's job. The
interpreter should lock the "current directory" for exw[c].exe to be the one
where the file which is being run lies, and nullify any change not deliberately
made by the .exw being run. Otherwise, users should be specifically advised about
the seemingly random changes it may undergo and their consequences.

CChris