[MPlayer-users] playlist file syntax

[The Wanderer]

James Gatt wrote:

> Quoting The Wanderer <inverseparadox at comcast.net>:
> 
>> James Gatt wrote:

>>> Do you know anyone who puts double quotes in filenames? I know
>>> you *can*, but...
>> 
>> I sometimes do.
>> 
>> I have an archive of digital copes of episodes of various TV series
>> on my hard drive(s), and I make it a habit to put the title of each
>> episode in its filename. In a few cases, there are double-quotation
>> marks in the title, so the same will appear in the filename.
>> 
>> Also, I prefer to give non-episode non-movie video clips
>> descriptive filenames, and that sometimes involves setting part of
>> the description apart from the rest - in a way which is best done
>> with quotation marks. It hardly happens with every file, but it's
>> still more common than you might think.
>> 
>> (I've also been stymied, on occasion, by being unable to similarly
>> put the slash character in filenames (even escaped)... but that's a
>> whole 'nother rant.)
> 
> I generally try to avoid putting characters in filenames which make
> the filenames non-portable across platforms (typically Linux and
> Win32). If I see these same restrictions in an application program,
> it does not bother me.

One of the advantages of Linux, to me, is that it supports filesystems
which *do* allow me to use characters in filenames which would not be
permitted under windows. Since the lack of that limitation is one (small
but not negligible) part of the reason I prefer Linux to Windows, why
would I voluntarily enforce Windows' file-naming rules on myself when I
blessedly don't need to?

Yes, yes, cross-platform portability. I know some people do need to be
able to interoperate with Windows filesystems. I just don't like to be
*required* to do so, and if I came across a program which contained
those restrictions and enforced them even when they were not necessary,
I would be rather unlikely to be happy with (or to use) it.

>>> After all, is there a way to put filenames containing linefeeds
>>> into playlists? If not then there are already restrictions in the
>>> filenames allowed by the playlist format over and above those of
>>> the file system.
>> 
>> ..filenames containing newlines - there's an idea which had never
>> occurred to me... and I *really* don't see how that could be
>> useful.
> 
> The point being not so much about whether this is a useful feature,
> but that it is a feature of the Linux file system that the current
> playlist format (as far as I know) already does not support.

Oh, that much is understood - I just wasn't sure why the feature existed
in the first place, except inasmuch as "it would be harder to forbid it
than to permit it and why should we go out of our way to forbid it?" is
a reason (which of course it is).

> This makes the set of filename characters supported in the playlist
> format arbitrary, which makes the argument about not supporting
> certain filenames a moot point, especially as the current utility of
> the entire playlist system is so low.

I'll agree that it might make sense to revise the playlist format, but
*only* in ways which expand functionality, not in ways which reduce it.
Removing current functionality to permit adding other functionality is
not, in my present view, acceptable.

One major advantage of the current playlist format is its extreme
simplicity: a simple 'ls directory/ > filename' produces a valid
playlist. (I've used that on occasion, although the only times it's been
a necessity have been with programs other than MPlayer - it can be nice
to work around the fact that the shell does not support a
post-wildcard-expansion command line of more than a certain length.)
Also, MPlayer does AFAIK support other playlist formats; if you want
extra features which are in those other formats, why not simply use one
of them?

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.