Project

General

Profile

Bug #3243

Ampersand in configuration files isn't escaped automatically

Added by NASSOOR ᠎R over 1 year ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Configuration
Target version:
Start date:
03/09/2016
% Done:

100%

Reproducibility:
Always
Operating system:
Other
Severity:
Normal

Description

I used a data folder which had the ampersand symbol "&" in the directory address.

When I launch openmw.exe, with an active esp from that folder, it throws an error with the plugin file name saying the content file does not exist.


Related issues

Related to OpenMW - Bug #3045: Settings containing '#' cannot be loaded Closed 11/29/2015
Duplicated by OpenMW - Bug #4157: Data paths with "&" fail to work Rejected 10/14/2017

History

#1 Updated by scrawl . over 1 year ago

  • Related to Bug #3045: Settings containing '#' cannot be loaded added

#2 Updated by scrawl . over 1 year ago

Have you tried to put the data= line in quotes? I.e.

data="/path/to/the & data & folder/" 

#3 Updated by NASSOOR ᠎R over 1 year ago

Jannik Heller wrote:

Have you tried to put the data= line in quotes? I.e.

[...]

Yes, it was already in quotes.

#4 Updated by scrawl . over 1 year ago

  • Status changed from New to Confirmed

#5 Updated by AnyOldName 3 over 1 year ago

After an embarrassing amount of investigation, I've decided that this is actually intended and sensible behaviour from Boost's program_options library. The ampersand character is used as an escape character in file paths to allow characters that have a meaning in the cfg file to be used in paths - in Unix, it's valid to have a file path containing the double quotation mark character, such as /path/to/mod/called/"Dave's Amazing Mod"/datafiles. This can be entered into openmw.cfg as data="/path/to/mod/called/&"Dave's Amazing Mod&"/datafiles". However, this means that a single ampersand character has the potential to trip up any code using the resulting boost::filesystem::path object, so they are removed. Instead, a pair of ampersands should be used, so C:\Games\Morrowind\Mods\Morrowloading&\Data Files should be entered as data="C:\Games\Morrowind\Mods\Morrowloading&&\Data Files". I have confirmed that this does indeed work.

I propose that we mark this as not a bug, and write some documentation somewhere so that it's clear to users what's going on.

#6 Updated by scrawl . over 1 year ago

If we decide that this is the expected behaviour for the cfg-files, then the launcher needs to produce conforming cfg-files (i.e. escape problematic characters on writing).

#7 Updated by AnyOldName 3 over 1 year ago

Currently, I'm not aware of any way to add or modify mod folders via the launcher, so there's not any code that needs updating there. Additionally, Boost is interpreting esp/esm/omwgame/omeaddon files in openmw.cfg as raw strings, so is adding the escape characters itself when loading them, so what the launcher outputs is fine.

#8 Updated by Dark Locq 9 months ago

This shouldn't be tagged as a Windows problem; it's also Mac and Linux. This is a bug or at least a very severe misfeature. I have no idea why anyone would choose as OpenMW's escape character a very common character like "&", which is used constantly in natural language including the names of billions of file directories/folders by people everywhere. Pick something people don't use much in names of things, like "^". Until this is fixed, please update all the documentation (I already took care of https://wiki.openmw.org/index.php?title=Mod_installation on the wiki) to mention the can't-use-an-ampersand issue. Most people who run into this problem are not going to figure it out on their own, and are going to give up on OpenMW's multiple data folders approach.

#9 Updated by AnyOldName 3 9 months ago

  • Operating system changed from Windows to Other

The comment button seems to have been replaced with an edit issue button, so hopefully I'm not going to break everything (e.g. the issue description) by typing into this box. Anyway...

It was whoever wrote a certain component of Boost that chose the ampersand to be the escape character, not any of us, so debates as to it being a stupid choice are moot. I wrote a piece of code that changed how things are passed to Boost during config parsing that I could adapt to change the escape character in the data= lines, and have discussed this with Zini in the past. It was decided that while picking a sensible escape character that can be used anywhere in OpenMW's config files would be sensible, stuff like actually picking how it's done is a pretty big deal, and while it's only really stupid in one case, it's not a high priority big deal. It was also mentioned that the multiple data directories system may be replaced post-1.0 with something more akin to bsa archives (but they'd also be able to contain, for example, the actual plugin files), which would eliminate this altogether. While I see problems with this, we're kind of in a rut.

Maybe once I've finished my degree in a few months I can make nagging the powers that be about this my full time job, but until then, it's just a case of making the documentation obvious.

#10 Updated by Alexei Dobrohotov 2 months ago

  • Subject changed from Some characters can't be used in openmw.cfg to Ampersand in configuration files isn't escaped automatically
  • Category set to Configuration

#11 Updated by Alexei Dobrohotov about 1 month ago

  • Duplicated by Bug #4157: Data paths with "&" fail to work added

#12 Updated by AnyOldName 3 about 1 month ago

I'm going to quickly mention a sub-task here: the Wizard doesn't escape ampersands automatically, either. That should be a trivial fix.

#13 Updated by AnyOldName 3 about 1 month ago

I jinxed it by saying it should be a trivial fix. It is not.

#14 Updated by AnyOldName 3 about 1 month ago

That part of this is fixed by this PR I just made: https://github.com/OpenMW/openmw/pull/1502

It could be argued that this resolves the issue as it is currently titled, but I'm still in favour of having an extra launcher page to add data directories, and that'll inevitably end up with some kind of bug to do with this unless I'm the one who implements it.

#15 Updated by Alexei Dobrohotov about 1 month ago

  • Status changed from Confirmed to Resolved
  • Assignee set to AnyOldName 3
  • Target version set to openmw-0.43
  • % Done changed from 0 to 100

That'd be "if and when" issue tbh.

#16 Updated by Alexei Dobrohotov about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF