[Gambas-user] Path specification
Tobias Boege
taboege at gmail.com
Sun Aug 19 16:31:45 CEST 2018
On Sun, 19 Aug 2018, Gianluigi wrote:
> Hi Tobias,
> one final clarification.
> When you write:
> "If you want access from the component code to resources in the currently
> running project, then you use "../foo.txt".
> gb.web.form does this, for example, to serve files in your project's
> .public folder (think favicon, css and javascript resources) without you
> having to think about it."
> You mean that with "../" we access files in read-only mode, right?
> If we need to write to the file we have to copy it to a user directory
> (e.g. Try Copy "./foo.txt" To sPath &/ "foo.txt")
>
Yes, you should never[*] write to files in your project directory because
you never know if your program might be running from an executable archive
(*.gambas file) later. In that case, the project files will be bundled
into the archive and the interpreter will redirect access to relative paths
into that in-memory archive. There is no support for mutating the archive,
neither in-memory nor on-disk. An error about the files being read-only is
raised instead. This is nothing special about "..", it applies for all
relative paths. The difference between "." and ".." is just in which archive
components look for files.
For the same reason, you can consider a program refering to files inside
Application.Path to be broken[*]. If the code is packaged into an executable
archive, Application.Path will be meaningless.
Regards,
Tobi
[*] Exceptions apply, but rarely. I think there is some Gambas code
out there which generates Gambas code for the project. If you know you
are only ever using that functionality while developing or debugging,
it's fine to write to files in your project. But otherwise, you are
effectively forbidding your users from generating .gambas files.
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
More information about the User
mailing list