The -d, -D and -a options do not allow paths containing a colon

[josch]

Currently, the argument to -d, -D and -a is split by the first colon. This means that the path to the directory, specfile or tarball must not have a colon in it. This limitation should either be fixed or at least documented somewhere.

For fixing this I thought about replacing the call to strchr by strrchr but that will just shift the problem to the path inside the ext2 filesystem.

Another problem is, that strchr and strrchr operate on bytes and not on characters. This means, that all unicode characters containing 0x3A are also not supported in input paths -- that's a lot of characters.

One way to fix it would be to allow escaping the colon but then parsing becomes hard.

Another way would be to drop the colon syntax in favour of new command line arguments or by allowing the -d, -D and -a options to receive two arguments, so that the shell takes care of the splitting for us.

[bestouff]

Another problem is, that strchr and strrchr operate on bytes and not on characters. This means, that all unicode characters containing 0x3A are also not supported in input paths -- that's a lot of characters.

I don't think so. IIRC utf-8 is very well engineered, 7-bits characters are never part of a multibytes char. In fact each char in isolation can tell you if it's standalone or part of a multibytes char.
But yes, it should be documented and probably "escapable" somehow.

[josch]

You are right. I should've looked this up before making that claim. In UTF-8 encoding, every byte in a multi-byte encoding has a '1' as the first bit and thus cannot possibly have a 0x3A in it.