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