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
Issue is that when we specify filename with -o the subtitles
is written to that file and later when we want to save the video
to that file. the file already exists.
The progressbar() currently does not handle the case where the total size is
unknown. But with this change, progress() will internally use progressbar()
for its bar generation, while still supporting a more basic progress info when
total size is unknown.
