[pulseaudio-discuss] [PATCH] Don't let user-set PULSE_RUNTIME_PATH values affect behaviour

[Glenn Golden]

David Henningsson <david.henningsson at canonical.com> [2014-10-20 08:35:33 +0200]:
> >>We don't have a use case for PULSE_RUNTIME_PATH. Other people may have a
> >>use case for it, but we don't know whether they want the directory to be
> >>created or not (we have certainly never promised them any particular
> >>behaviour).
> >>
> >>If you don't think it's a good idea to deprecate the variable, then
> >>let's not do that.
> >>
> >
> >Based on the above discussiion, since it seemed to have been decided not to
> >deprecate PULSE_RUNTIME_PATH, I tried a few experiments to see what I could
> >learn about its [undocumented] symtax/semantics, in order to document it
> >properly in my writeup.  I was a bit surprised at what I found:
> >
> >Given the name of the envar (ending in "...PATH") I mistakenly assumed that
> >it would be treated as a PATH-like variable, i.e. a list of comma-delmited
> >paths to putative runtime dirs which would be tried in sequence.  So I tried
> >this experiment:
> >
> >     $ unset XDG_RUNTIME_DIR		# Just to be safe
> >     $ unset XDG_CONFIG_HOME		# Just to be safe
> >     $ export PULSE_RUNTIME_PATH='/tmp/a:/tmp/b:/tmp/c'
> >     $ rm -fr /tmp/a  /tmp/b
> >     $ mkdir /tmp/c
> >     $ [kill any running pulseaudio processes by hand]
> >     $ pulseaudio -v --start
> >
> >My expectation was that the runtime directory would be created in /tmp/c.  But
> >instead, it was created in a directory named '/tmp/a:/tmp/b:/tmp/c'.  I.e. it
> >evidently treated $PULSE_RUNTIME_PATH not as a list of paths to be tried in
> >sequence, but as the name of a directory, and which is evidently to be created
> >[if possible] even if non-existent at the time the PA server is started.
> >
> >Thinking that perhaps I'd made an unwarranted assumption about the delimiter
> >character being colon, I tried the same experiment as above except using a
> >single space as the 'delimiter'.  Same thing: The runtime dir was again created
> >in a directory whose name was precisely the contents of PULSE_RUNTIME_PATH,
> >i.e.  the directory was named  '/tmp/a /tmp/b /tmp/c'.
> >
> >Is it really intended to work this way or is this a bug?  If it is intended
> >to work as it does, then imo, the name choice for the envar is very misleading,
> >given the defacto convention that envars named as "....PATH" behave as PATH-
> >like variables (e.g. CDPATH, MANPATH, MAILPATH, INFOPATH...).
> 
> Given your findings, how about this: let's say that PULSE_RUNTIME_PATH is
> deprecated in the documentation (and refer to XDG_RUNTIME_DIR as a preferred
> solution), and also document the above shortcoming / unexpected behaviour? I
> e, if it's deprecated, we don't have to fix it. :-)
> 

OK, I'll handle it that way in the writeup, thanks.

Btw, just to clarify for completeness, there's a typo in my post:
>
> ... i.e. a list of comma-delmited ...
>                    ^^^^^

Not comma, but "colon" is what was intended (and what was actually used in
the first experiment, as shown.)