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

bugzilla-daemon at mindrot.org
Thu, 31 Aug 2023 17:12:08 -0000

--- 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.