I tried to execute:
daml sandbox &> log.log &
I expected to see log lines in log.log (e.g. Starting Canton sandbox.) but there is nothing even after minutes.
Is this the correct behaviour and if yes why?
The issue here is buffering. Writing to stdout in a terminal usually defaults to line buffering so you see every line as soon as it is written. However, writing to a file usually is block buffered meaning that things only get written to the file once a full block is full.
In your example, that never happens so you don’t see any output. Note that it will be written once you kill sandbox (gracefully via SIGTERM not SIGKILL). So it’s not that the output isn’t written it’s just not flushed to the file because the block is not full.
I think it would be reasonable to say that we should always use line buffering for this.
In the meantime, you can use unbuffer to work around it:
unbuffer daml sandbox > log.log
1 Like
Thank you, this makes sense.
Just a note: unbuffer is in the expect package (at least on Ubuntu) command-not-found.com – unbuffer
By the way, I (obviously) had the same problem with Python / subprocess / Popen (“no output on process.stdout”, reading from there blocks forever 
I wonder whether there is a better solution for that case than using unbuffer.
You might be able to somehow disable buffering from within Python, i.e., somehow replicate what unbuffer is doing but I’m not familiar with the details there.
Having read the code of unbuffer I do not recommend trying to replicate it
I opened Assistant/daml-helper should always line-buffer · Issue #14415 · digital-asset/daml · GitHub to switch to line buffering our code which would remove the need for unbuffer or similar workarounds.
1 Like
To be honest, that was my guess that it’s a bit more complex than one would like.