Red Hat Bugzilla – Bug 892744
[RFE] Detect file names with ~ in the path or name
Last modified: 2013-09-16 11:01:45 EDT
Description of problem:
Sometimes there are packages that have ~ in the filename because it was edited by an editor that saves a backup copy and both upstream missed it and the install script is too trusting. The problem is that if "rpm -ql" is used to get a list of files and a shell script processes it, then it will follow a set of rules to resolve the path and it causes havoc.
One example package that can be used for testing purposes is ClanLib1-devel-1.0.0-11.fc18.
For reference, ClanLib1-devel-1.0.0-11.fc18 can be grabbed here:
I think "~ in the filename" can be a too general thing to whine about, but if the filenames containing ~ in this ClanLib1-devel package are backup files, they seem to be following a naming pattern we could try to detect. What editor creates backup files with this pattern?
The regex used to flag files as backup files is in /usr/share/rpmlint/FilesCheck.py, backup_regex.
I don't know what editor they were using. But if you look at the file names in the package, some have **) which, while legal names, are clearly not advisable names as they will cause scripting problems. For example,
I'd say, *,~,(,) are not advisable to belong in file names.
(In reply to Steve Grubb from comment #0)
> One example package that can be used for testing purposes is
Which path? This:
is generated documentation for a C++ destructor, from this program:
# PCE2 - Perl C++ Extractor version 2
# Copyright 2000-1999, Karl Nelson <email@example.com>
# Copyright 1997, Mark Peskin <firstname.lastname@example.org>
This is probably a generator bug/missing feature because the "~" character is not really that portable in file names. But it's definitely not a backup file.
Emacs creates backup files ending in "~", or "~" with a version number (which is extremely rare, though).
Inner or anonymous Java classes use "$" in file names, and we really can't change that, so there's no way around fixing shell scripts to deal with metacharacters properly, I'm afraid.
Here's a Java example: /usr/lib/jvm/java-1.8.0-openjdk-18.104.22.168.x86_64/demo/applets/Blink/Blink$1.class in java-1.8.0-openjdk-demo-1:22.214.171.124-0.9.b89.fc19.x86_64.
Even files with ` exist, in ucblogo-6.0-11.fc19.x86_64 and synopsis-doc-0.12-9.fc19.x86_64.
The point is that since we are in control of our very own packages, we can choose to make life easy or hard on ourselves.
(In reply to Steve Grubb from comment #5)
> The point is that since we are in control of our very own packages, we can
> choose to make life easy or hard on ourselves.
True, but as I explained, we really can't outlaw $. With that in mind, banning ~. ' or ` will not actually simplify things that much, will it?