On Sunday, 31 August 2014 at 09:51:13 UTC, Marco Leise wrote:
Am Sun, 31 Aug 2014 09:01:23 +0000
schrieb "David Chin" <[email protected]>:
Hi all,
On WebFaction, my Linux shared hosting server, I created a
simple "Hello, World!" script in a file named "hello.d".
Attempting to run the script with "rdmd hello.d" yielded no
error messages, and strangely, no output.
However, the following works, and I see the output:
(1) dmd hello.d
(2) ./hello
Running "rdmd --chatty hellod.d" shows D writing some files to
/tmp folder and calling exec on the final temp file.
I suspect the reason I'm not seeing any output using rdmd has
something to do with WebFaction's security policies
disallowing any execution on files in the /tmp folder.
May I request that rdmd check, say, the environment variables
tmp or temp for the path to write the temporary files in?
Thanks!
Sorry for hijacking. I believe any program should remove what
it placed in /tmp on exit and actively manage any cached files
under /var/lib, e.g. by age or size of the cache. In the case
of rdmd, I'd even prefer to just do what most native compilers
do and place object files alongside the sources, but allow
custom object file directories. Usually I wouldn't say
anything, because endless bike-shedding ensues, but it looks
like now there is a technical argument, too. :p
There are some other technical arguments, too, but it looks like
they speak against /var/lib:
* Permissions: /var/lib is not world-writable; there would either
need to be a new world-writable directory below it (bad
practice), or rdmd would have to run as setuid with a dedicated
user. That's not a good idea either, because users would then
have access to other users' binaries.
* Similarly, you don't want to store the binaries next to the
sources if those are in /usr/bin, for example.
* /tmp is often cleaned regularly. But maybe /var/tmp would be
more appropriate than /tmp.
About the original post: While the cause of the problem seems
clear in your case, rdmd also doesn't print anything when the
compiled program segfaults. This could be another candidate for
the observed behaviour.
