[MPlayer-users] playlist file syntax

[James Gatt]

Quoting The Wanderer <inverseparadox at comcast.net>:

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

A nice ideal, when possible.

> Removing current functionality to permit adding other functionality is
> not, in my present view, acceptable.

It is not always possible to design something from the beginning to cater for
it's final requirement, especially when the final requirement is not fully
understood at the beginning. For this reason it is sometimes necessary to
restrict certain functionality later on in the lifetime of a project in favour
of adding functionality that is more universally desired. If you decide never
to do this, you will always be crippled by supporting the legacy.

> 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?

I wasn't questioning the specific features, just the blanket desire not to
support anything which breaks the current (extremely limited, and therefore not
all that useful) functionality in a few rare instances.

I think I have made my point now so I won't be drawn any more on this issue.

Regards,
James.