This is a long reply so first of all:
1. I'm satisfied with current behaviour of TProcess.Execute and If I would be a main developer I would not implement the attached patch in trunk for more than just a single reason.
2. You should not invest any resources in this anomaly. Have you seen the following link!?
http://bugs.freepascal.org/view.php?id=27670 Not discouraged yet, read twice paragraph E
. I would not try to reproduce this situation.
"
Maybe the difference is the actual current directory before executing?"
This is what I've suspected, too. Maybe this post needs a brief introduction in chronological order:
A. Apparently Lazarus doesn't always rebuild itself properly. I think I've removed the influence of operating system file cache.(* may be read at the end of the post)
B. Assuming that the forum post anomaly appears from a programming mistake done by me, well, I don't directly use "
chdir" inside the application that calls other executables. This means that current working directory would be changed only by LCL/FCL/RTL/LAZARUS_IDE_THROUGH_A_PATH_MODIFIER_ROUTINE,LOCAL_CONDITIONAL_COMPILATION.... I don't know what other reasons may be involved. For my own knowledge, is there a conditional based on running an application within Lazarus, something like "csDesigning in ComponentState"? "csDesigning in ComponentState" doesn't say if the application runs within Lazarus.
C. The exception is risen within TProcess.Execute, but this doesn't mean that the problem is inside that routine.
D. Maybe one core developer, during the history of Fpc or Lazarus development, made a confusion regarding curent directory usage. Together with the initial post, the first two replies of this forum post clearly state that such automation is not welcome. I agree with the designed behaviour, but it's an easy to make misinterpretation(or expectation). This means that there is a possibility that a routine like "fileexists", "directoryexists", "findfirst" or whatever else, might change the working directory internally without reverting back. This is a possibility, not something certain. It looks unlikely to me but I've seen such confusions. Look at lazarus/lcl/graphtype.pp.TRawImageDescription.Init_BPP*. It's just an example where copy/paste(see the comment at procedure "TRawImageDescription.Init_BPP1(AWidth, AHeight: integer);") might lead to misinterpretations/inconsistencies. I've mentioned a 24bit related comment, but for some people bitsperpixel(bpp), pixelformat(pf),... what means "depth" variable inside there!? It's just an example of another not so likely situation that may lead to confusion or misunderstanding. Lazarus has a history of LCL graphics related issues, proof that there is a possibility that a simmilar situation might repeat with fpc.
E. Due to requirements(OS, FPC(svn ~30100)/Lazarus(1.4.0) versions involved...), paragraph A can't be reproduced easily by other people. Without a Lazarus stable release paragraph "A" can't be verified. Also, the computer I use to do the tests is known to have "personality", meaning that I always keep into account variations from required/expected/considered_normal behaviours.
(*) What follows here is a long and boring explanation for paragraph A, nothing more.
A different approach to updating Lazarus is presented in the following link(you don't have to read it because I'll resume what I consider is important)
http://forum.lazarus.freepascal.org/index.php/topic,28519.0.html The presented Lazarus update process consists in running an external tool that creates/overwrites/modifies some files and removes some files/directories. The presentation runs an external application from the Lazarus tool menu, meaning that Lazarus is running. After the external tool does it's job the user rebuilds Lazarus. It's a very easy approach for the Lazarus user, but there is a hard to notice anomaly, an annomally that doesn't bother anyone except for those reading this part of the forum post
. If a user modifies his stable release with a development(svn) version and then reverts back to the stable release, even though the source files are identical, no matter how many times the user rebuilds Lazarus, when Lazarus starts, it will show the development version on the splash screen, not the stable one(1.4.0 in the original post). The user may rebuild Lazarus clean as many times as he wants, as long as it's rebuilt using the "Tools" menu it will show a development version at splash screen, not the real version of the source files/directories. If the user closes Lazarus and rebuilds it using "make clean all" in a terminal window, the stable version will appear on the splash screen.
Initially I thought the problem was that Lazarus opened some files before running the external tool, Linux caches those files and uses them during child processes. The fact that the user can close Lazarus, manually start it again using startlazarus, rebuild it clean using an external application(fpc) and still have an obsolete information on the splash screen makes me wonder. It's not a problem of OS cache, it's not an OS problem of data read within files, it's not a particular issue with a particular source file modification, maybe the problem lies somewhere in the way Lazarus is designed to rebuilding itself, or maybe it's something fpc related.
Maybe the source of the anomaly has been fixed in the meantime but I'm unable to verify it because I need a latest fpc trunk compilable and runnable Lazarus stable version. I can't compare two svn Lazarus versions. I'm the only one that noticed this situation and I think I've done something good at documenting it and now we should let it go. If the situation gets worse I(or somebody else) will revive this forum post.
Thank you very much. If I consider I find something useful I'll append that to this post.