Talk:Make a backup file: Difference between revisions
→Assumes unix
Line 11:
::: i think <code>dlopen</code> is ok, i am not sure though, one question i am interested in is: can i deploy a program without relying on dependencies that i can not control? what if a user wants to run the program in a chroot or jail environment where <code>mv</code> might be missing. <code>dlopen</code> would be ok here only if the library to be opened somehow comes with the language, like it is a standard dependency of the language (as opposed to a dependency of just this task). this partly answers the case where the language implements rename using <code>mv</code> because in such a case <code>mv</code> would also be a standard dependency of the language. although i still would like to prefer a version that doesn't rely on external tools and processes.
::: in any case, if you can not avoid running an external process or if you dlopen a 3rd party library then please point this out in the description.--[[User:EMBee|eMBee]] 17:07, 10 November 2011 (UTC)
:::: Hmm... this warrants some thought: libc is the portable (documented) interface to the unix kernel. It can hypothetically be a static library but that is extremely rare nowadays -- almost everything requires an external libc. That said, there's also the question of "which libc", and the one used at build time is probably the right answer to that question (there will be a hard coded path in the executable which references libc for almost every working program out there in unix land). Or, that's how I would like to characterize the problem. And I think this thinking routinely applies in most all chroots. --[[User:Rdm|Rdm]] 17:14, 10 November 2011 (UTC)
| |||