File bindings don't work with GLib 2.77.3

[sachahony]

I have updated my glib2 from 2.77.2 to 2.77.3. After the update I can no longer enter into tar.bz2 files. Reverting back 2.77.2 solves the issue. Also the view archive shows a "binary" view rather than a "direcory" as if the file is not recognised.

Changelog of glib: ​https://download.gnome.org/sources/glib/2.77/glib-2.77.3.news

[andrew_b]

Are any other regressions with glib-2.77.3 besides tar?

Why component is mcview?

[andrew_b]

The significant change in GLib-2.77.3 is ​gkeyfile: Fix overwriting of GError.
Commit ​71b7efd08.

Solution: escape backslashes in mc.ext.ini: replace single \ with double one: \\.

[Toolybird]

We just hit this in Arch Linux because that commit made it into stable release glib2-2.76.5

[dimich]

I can confirm the issue with glib-2.76.5 in Arch: ​https://bbs.archlinux.org/viewtopic.php?pid=2118521

Not only compressed tar archives affected but other suffixes too, e.g. .mp4, .odt

[zaytsev]

Oh man, why they would handle escape sequences in INI files in the first place o_O ?

Maybe we can just switch from g_key_file_get_string to g_key_file_get_value API, because otherwise every stupid backslash would have to be escaped and it will make a bloody hell out of our regexes.

[ossi]

the ini parser is also used to parse .desktop files and such stuff, so supporting escapes in strings makes perfect sense.

it is a bit surprising that such a seemingly obvious bugfix has such side effects. i guess mc does something ... "interesting"?

[andrew_b]

Replying to zaytsev:

Maybe we can just switch from g_key_file_get_string to g_key_file_get_value API, because otherwise every stupid backslash would have to be escaped and it will make a bloody hell out of our regexes.

g_key_file_* API is used in mc indirectly via mcconfig engine. Changing g_key_file_get_string to g_key_file_get_value in mcconfig may break the handling of other INI files.

We already have INI files with escaped backslashes: mc.lib, Syntax (it is not INI but nonetheless), probably some others. I think mc.ext.ini should be consistent with them.

[zaytsev]

it is a bit surprising that such a seemingly obvious bugfix has such side effects. i guess mc does something ... "interesting"?

I'm not sure I would define this as "interesting". I think it's just missing error handling, the usual C stuff.

We already have INI files with escaped backslashes: mc.lib, Syntax (it is not INI but nonetheless), probably some others. I think mc.ext.ini should be consistent with them.

You are right, but exactly for this reason I find them to be disgusting and actually see no reason why we should support escape sequences in the configuration files. So I'd rather break everything while we are at it :-) But it's up to you.

[andrew_b]

Probably the story isn't finished yet: ​https://gitlab.gnome.org/GNOME/glib/-/issues/3095

[zaytsev]

​https://gitlab.gnome.org/GNOME/glib/-/issues/3094

[andrew_b]

Ticket #4505 has been marked as a duplicate of this ticket.

[birdie]

I thought I was going crazy. Thanks, Andrew.

[birdie]

A quick temporary fix for the affected users:

sudo cp -a /etc/mc/mc.ext.ini /etc/mc/mc.ext.ini.bak
sudo sed '/Regex=/s/\\/\\\\/g' -i /etc/mc/mc.ext.ini

[andrew_b]

So, I propose the following:

• escape backslashes in mc.ext.ini to be consistent with other files were regexps are used;
• use g_key_file_get_value instead of g_key_file_get_string to avoid parsing of key value in GLib.

Replying to zaytsev:

actually see no reason why we should support escape sequences in the configuration files

Escape sequence is a part of key definition for various terminals: https://midnight-commander.org/browser/misc/mc.lib#L15

[andrew_b]

Branch: 4502_mc.ext.ini
Initial changeset:2da7ef347d1c48e4ad8e73f5135cfe8a363e6c1f

[andrew_b]

Some tests failed.

[andrew_b]

The usage g_key_file_get_value instead of g_key_file_get_string requires a lot of changes in test. Let's leave it as it is.

[andrew_b]

Merged to master: [e8c4677b7e10c43f673e6542a86d3ea3ccf4f95e].

[zaytsev]

On macOS:

zaytsev@Yurys-MBP Downloads % file sample.war 
sample.war: Java archive data (JAR)

This is what we have to support:

# Java Jar files
>(26.s+30)	leshort	0xcafe		Java Jar file data (zip)
!:mime	application/jar
>(26.s+30)	leshort	0xcafe		Java archive data (JAR)
!:mime	application/java-archive

In mc.ext:

[jar]
Type=\(Java\ (Jar\ file|archive)\ data\ \((zip|JAR)\)

Enter does not work. Also confirmed on Ubuntu 22.04:

​https://bugs.launchpad.net/mc/+bug/2062968

What works is the following:

[jar]
Type=\\(Java (Jar file|archive) data \\((zip|JAR)\\)\\)

It looks like we have a big problem with escaping:

1. Spaces should not be escaped
2. Literal parens should be escaped like this: \\( and not like this \(

Andrew, what do you think?

[andrew_b]

Replying to zaytsev:

1. Spaces should not be escaped

Should not or may not? Are correctly escaped spaces worse than not escaped?

2. Literal parens should be escaped like this: \\( and not like this \(

Agree. Moreover, . is escaped as \\., [ as \\[.

[zaytsev]

Should not or may not? Are correctly escaped spaces worse than not escaped?

Good question. In my opinion they are worse, because it's not obvious, which lead to current problems and also it looks like a wood. If escaping is not necessary, I would not use it to keep the patterns simpler, more readable and more understandable.

Agree.

I think at the moment we only have escaped spaces, which I would unescape, wrongly escaped parens and a missing dot:

# dot unescaped
Regex=.g?mo$

[andrew_b]

Branch: 4502_mc.ext.ini_fixups
Initial changeset:2384a486f7a9ae3e6da6039648edbc8bad58159f

[zaytsev]

The JAR thing was still wrong, pushed some fixups, thank you!

[andrew_b]

Merged to master: [942869713448691f377b91f26cf9ebdac9e2e4c9].

git log --oneline cb97cd263..942869713