--logdir unexpectedly interprets commas and colons

[iron9light]

Consider Stack Overflow for getting support using TensorBoard - they have a larger community with better searchability:

https://stackoverflow.com/questions/tagged/tensorboard

For bug reports, please include the following:

• TensorBoard version (from pip package, also printed out when running tensorboard) 1.8.0
• TensorFlow version if different from TensorBoard
• OS Platform and version (e.g., Linux Ubuntu 16.04) Win10 64bit
• Python version (e.g. 2.7, 3.5) 3.6.4
• For browser-related issues:
  • Browser type and version (e.g. Chrome 64.0.3282.140)
  • Screenshot if it's a visual issue

Please describe the bug as clearly as possible, and if possible provide a minimal example (code, data, and/or command line) to reproduce the issue. Thanks!
How can I pass a logdir with comma in it? It's not work even I put the path in the quotes.

[nfelt]

Commas are interpreted as separating multiple logdirs passed to the --logdir flag as a single argument, so they can't be present in the directory names as it currently works.

You have a few options:

• Rename the directory to avoid the comma
• Create a symlink to the directory that doesn't use a comma, and point TensorBoard at that instead
• Point TensorBoard at a directory one level up from the one that contains the comma (it will descend recursively into child directories, so this is best to use if the parent directory doesn't contain many files/subdirs other than the one with the comma)

[iron9light]

I tried 3 firstly, it works until I got more than one dir whose name contains ",".
Then I go with 1 and changed a lot of code and folder name :(

I think it's a bad design if it cannot support dir name with "," since it's a valid char for dir name.
And I wish it could support wildcards.

[jart]

We also don't support colons probably. We could probably run the logdirs through a URI decoder, so you can specify those commas as hex. See also argparse change in #1221

[nfelt]

We should fix this by 1) making it more obvious that a special interpretation is happening, 2) giving a way to escape/avoid this interpretation, and 3) ideally changing this feature to conflict less with valid directory names.

In the mean time, a workaround is to use another name to refer to the directory - e.g. creating a symlink, or by CD'ing into it and using "./" as described in #2229.

For the colon case, it should also I think be possible to work around it by adding a prefix name with a colon, e.g. for --logdir /tmp/foo:bar instead pass --logdir myname:/tmp/foo:bar.