win32 is a cursed abomination which has "drive letters" at the root of
the filesystem namespace for no reason. This requires special handling
beyond tolerating the idiotic "\" path separator.
Even more cursed is the fact that a path starting with a drive letter
can be a relative path. For example, "c:billsucks" is actually a
relative path to the current working directory of the C drive. So for
example if the current working directory is "c:/windowsphone", then
"c:billsucks" would reference "c:/windowsphone/billsucks".
You should realize that win32 is a ridiculous satanic trash fire by the
point you realize that win32 has at least 26 current working
directories, one for each drive letter.
Anyway, the actual problem is that mpv's mp_path_join() function would
return a relative path if an absolute relative path is joined with a
drive-relative path. This should never happen; I bet it breaks a lot of
assumptions (maybe even some security or safety relevant ones, but
probably not).
Since relative drive paths are such a fucked up shit idea, don't try to
support them "properly", and just solve the problem at hand. The
solution produces a path that should be invalid on win32.
Joining two relative paths still behaves the same; this is probably OK
(maybe).
The change isn't very minimal due to me rewriting parts of it without
strict need, but I don't care.
Note that the Python os.path.join() function (after which the mpv
function was apparently modeled) has the same problem.
The path functions need to access the option that forces non-default
config directories. Just add it as a field to mpv_global - it seems
justified. The accessed options were always enforced as immutable after
init, so there's not much of a change.
I've decided that MP_TRACE means “noisy spam per frame”, whereas
MP_DBG just means “more verbose debugging messages than MSGL_V”.
Basically, MSGL_DBG shouldn't create spam per frame like it currently
does, and MSGL_V should make sense to the end-user and provide mostly
additional informational output.
MP_DBG is basically what I want to make the new default for --log-file,
so the cut-off point for MP_DBG is if we probably want to know if for
debugging purposes but the user most likely doesn't care about on the
terminal.
Also, the debug callbacks for libass and ffmpeg got bumped in their
verbosity levels slightly, because being external components they're a
bit less relevant to mpv debugging, and a bit too over-eager in what
they consider to be relevant information.
I exclusively used the "try it on my machine and remove messages from
MSGL_* until it does what I want it to" approach of refactoring, so
YMMV.
HOME isn't set by default on Windows. But if the user does set it,
prefer it by default.
Enables stuff like --log-file=~/mpv.log to work, even if HOME isn't set.
The history goes back to 2001 or so, but everyone involved with still
existing code has agreed.
One person who could not be reached yet (elevengu) has changes in this,
which as far as I can tell were overwritten anyway at a later point.
The code for expanding the ~~ prefix used mp_find_config_file(), which
strictly looks for _existing_ files in any config path (e.g. not just
the user-local one, but also system-wide config). If no such file
exists, it simply returns NULL, which makes the code below just return
the literal, unexpanded path.
Change this so that it'll resolve the path to the user-local config
directory instead.
Requested in #3591.
If you do "mpv /bla/", and then branch out into sub-directories using
playlist navigation, and then used quit and watch later, then playing
the same directory did not resume from the previous point. This was
because resuming is based on the path hash, so a path prefix can't be
detected when resuming the parent directory.
Solve this by writing each path prefix when playing directories is
involved. (This includes all parent paths, so interestingly, "mpv /"
would also resume in the above example.)
Something like this was requested multiple times, and I want it too.
The "PWD" enviornment variable is described by POSIX. We don't go to
length to verify its contents, but just trust it.
This affects the logic for resuming playback.
This was completely broken. It was checked manually in some config
loading paths, so it appeared to work. But the intention was always to
completely disable reading from the normal config dir. This logic was
broken in commit 2263f37d.
The manual checks are actually redundant, and are not needed if
--no-config is implemented properly - remove them.
Additionally, the change to load the libmpv defaults from an embedded
profile also failed to set "config=no". The option is marked as not
being settable by a config file, and the libmpv default profile is
parsed as a config file, so this option was rejected. Fix it by removing
the CONF_NOCFG flag. (Alternatively, m_config_set_profile() could be
changed not to set the "config file" flag by default, but I'm not
bothering with this.)
mp_find_config_file() will print the filename lookup and its result in
verbose mode. This is wanted, but gets inconvenient when it is done for
every playlist entry (for resuming).
Lookup the watch_later subdir only once and cache the result instead.
This drops the logic for loading the resume file from other locations,
which should generally be unnecessary, though might lead to confusion if
the user has mixed old and new config paths (which the user shouldn't).
Also add a mp_find_user_config_file() function for a more
straightforward and reliable way to get actual local configpaths,
instead of possibly global and unwritable locations.
Also, for symmetry, check the resume option in mp_load_playback_resume()
just like mp_check_playlist_resume() does.
Share most of the implementation of config file lookup between
mp_find_all_config_files() and mp_find_config_file().
Also move the check for config path overrides to mp_get_platform_path()
directly. From the point of view of config file lookup, this is a bit
stupid, but on the other hand increases consistency, as user path
resolution exposes the mp_get_platform_path() functionality directly to
the user.
Since commit 7381db60, strings like "~desktop/" were expanded as
platform-specific paths by mpv. Apparently this similarity to standard
Unix shell expansion caused confusion, so change it to "~~desktop/". The
shell doesn't expand this, so it should be better.
Somewhat less ifdeffery, higher flexibility. Now there are 3 separate
config file resolvers for 3 platforms (unix, win, osx), and they can
still interact with each other somewhat. For example, OSX for now uses
most of Unix, but adds the OSX bundle path.
This can be extended to resolve very specific platform paths, such as
location of the desktop.
Most of the Unix specific code moves to path-unix.c.
The behavior should be the same - if not, it is likely a bug.
Actually, it's pretty simple to look for multiple filenames at once,
since mp_find_all_config_files() is already a bit "special" anyway.
See #1569. Reverts most of commit db167cd4 (keeps osx-bundle.conf).
We certainly don't use the mplayer configuration dir. The name didn't
matter, but now that it's in user-visible output (as part of config.h
being dumped in verbose mode), it's a bit too strange.
mp_stat() instead of stat() was used in the normal code (i.e. even
on Unix), because MinGW-w64 has an unbelievable macro-mess in place,
which prevents solving this elegantly.
Add some dirty workarounds to hide mp_stat() from the normal code
properly. This now requires replacing all functions that use the
struct stat type. This includes fstat, lstat, fstatat, and possibly
others. (mpv currently uses stat and fstat only.)
Don't worry, your ~/.config/... paths are safe. This merely removes
handling of $XDG_CONFIG_DIRS for global paths.
Maybe there is a better solution for this, like still including the
"traditional" config dir. But I will leave the fine reading of this
(crappy) spec and fixing the code accordingly to someone else. So, if
anyone has interest in getting this behavior back, you will have to
write a patch. This patch should _also_ not break expected behavior.
Fixes#1060.
Until now, the config functions added various allocations to the user-
provided talloc context. Make it so that they're all under the returned
allocation instead. This allows avoiding having to create an extra
temporary context for some callers, and also avoids adding random memory
leaks by accidentally passing a NULL context.
mp_find_all_config_files() has to be changed not to return a pointer
into the middle array for this to work. Make it add paths in order
(instead of reverse), and then reverse the array entries after that.
Also remove the declarations for the win-specific private functions.
Remove STRNULL(); it's barely needed anymore and the functions are
not called with NULL filenames anymore.
This means normally the XDG config dir will be used. But if the old
config dir (~/.mpv) exists and the XDG config dir does not, then don't
create it.
To simplify the code, also make mp_path_exists() accept NULL paths. In
that case it's considered as not existing. (Funnily, on Linux this
already worked, because the string is passed directly to the kernel,
and the kernel will just return EFAULT on invalid memory.)
Search $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS for config files.
This also negates the need to have separate user and global variants of
mp_find_config_file()
Closes#864, #109.
Signed-off-by: wm4 <wm4@nowhere>
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
Including the "." in the returned extension was too inconvenient. I
think originally, the semantics were supposed to work like in Python,
but screw this.
Also, return NULL instead of "" on failure (which is what its only user
actually seems to expect).
There's a single mp_msg() in path.c, but all path lookup functions seem
to depend on it, so we get a rat-tail of stuff we have to change. This
is probably a good thing though, because we can have the path lookup
functions also access options, so we could allow overriding the default
config path, or ignore the MPV_HOME environment variable, and such
things.
Also take the chance to consistently add talloc_ctx parameters to the
path lookup functions.
Also, this change causes a big mess on configfiles.c. It's the same
issue: everything suddenly needs a (different) context argument. Make it
less wild by providing a mp_load_auto_profiles() function, which
isolates most of it to configfiles.c.
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
wm4
john
Niklas Haas
Ricardo Constantino
Pedro Pombeiro
Dmitrij D. Czarkoff
lzmths
Marcin Kurczewski
James Ross-Gowan
Kenneth Zhou