The q/kdb+ official documentation on the Tickerplant at https://code.kx.com/q/architecture/tickq/#uupd
References the file tick.q found here: https://github.com/KxSystems/kdb-tick/blob/master/tick.q
I can see the log file handle is obtained differently in tick vs endofday:
/ends in l::ld d
tick:{init[];if[not min(`time`sym~2#key flip value@)each t;'`timesym];@[;`sym;`g#]each t;d::.z.D;if[l::count y;L::`$":",y,"/",x,10#".";l::ld d]};
/ends in l::0(`.u.ld;d)
endofday:{end d;d+:1;if[l;hclose l;l::0(`.u.ld;d)]};
Do the two ways of running .u.ld make a difference? Everything is defined inside the .u namespace to start with.
Yes, the two ways make a difference, it is in fact mentioned in one of the comments at the top:
/2013.08.14 allow <endofday> when -u is set
When -u is set a kdb process running tick.q can't access any file outside of its current directory. For tick it's not a problem since it is called only once by the script itself but endofday is called by .u.upd (via .u.ts) which gets called by an external process publishing to the TP and would fail to load a tickerplant log file if it called .u.ld directly. Calling it via handle 0 bypasses this check.
See https://code.kx.com/q/basics/cmdline/#-u-usr-pwd-local
access to files outside the current directory for any handle context (.z.w) other than 0.
So even when -u is in effect you can use 0(..) to bypass it which is exactly what tick.q does