We should be able to assume that if we see literal " in the name of the
output file, the user really wants the quotes. Assuming otherwise opens a
can of worm. What else can't we trust in the environment?
On the Windows command line, \ has special meaning in strings, and it's not
the same as on normal platforms: it only has special meaning if it's
immediately followed by a " character, in which it case it will make the "
character be interepreted literally. That's what we've been seeing.
Incorrect command line on windows:
python svtplay-dl -o "C:\foo\"
Correct command line on windows:
python svtplay-dl -o "C:\foo\\"
This has been made harder to pinpoint because of the forgiving nature of
command line parsing on windows. For instance: The following command was
reported to work:
python svtplay-dl http://example.com/ -o "C:\foo\"
But only if the -o flag was the last argument. (Unclear if the trailing "
was passed on to the program or not.)
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/17w5ykft(v=vs.85).aspx
This happens when they publish information about the TV episode before
publishing the video stream. Probably due to some bug in SVT Play. The
web player is also unable the play the video, reporting "Can't play
the program, try again later".
When building from git, it can be useful to know which version
a user has at commit level resolution. When building in a git
repository, use git describe to generate a version string. If
HEAD matches a tag, use that. Examples:
$ ./svtplay-dl --version
0.20.2015.10.08-3-gbd75a67
$ git tag -a 0.20.2015.10.18
$ make
...
$ ./svtplay-dl --version
0.20.2015.10.18
make release is also adjusted, so that it overrides the version
value when building, so that official releases still only has the
tag.
