[Bug 3609] Support the special ${RANDOM} environment variable

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3609

--- Comment #2 from Ernesto Alfonso <erjoalgo at gmail.com> ---
> How would this actually work? $RANDOM doesn't end up anywhere usable other than the listening path on the remote side. Do you enumerate all paths there to figure out which one?

On the remote side the client program can use a glob like
/tmp/.x-service-*.sock. This is possible because I can control where
within the RemoteForward path the ${RANDOM} gets inserted.

> I suspect $RANDOM isn't the best solution for your underlying problem. 

The solution certainly works for me but if you have a better suggestion
I would be open to it.

> For a start, some shells already provide this with syntax that is incompatible with yours (e.g. https://man.openbsd.org/ksh.1#RANDOM).

Not sure I follow. I installed ksh and `echo ${RANDOM}` worked as
expected, how is that syntax incompatible?

> Furthermore, a merely random input is only part of an effective unique/temporary name facility.
That is exactly how the feature would be useful to me.

> Would an explicit unique/temporary name facility for forwarded Unix domain sockets be better? There is already an analogous thing for remote-forward ports, where a listener port number of 0 indicates that the server should allocate one and tell the client what it picked. We could do something similar here (say when passed an empty listen pathname). Would this work for you?

On the remote side I need to know where to look, so binding to a random
port or wouldn't be very useful. That is the reason I am using unix
sockets with a regular, globabble pattern and a fixed prefix.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.