Hi,
for some videos I got directory names containing control chars (I've found ^A and ^B). Sometimes this chars are confusing bash's TAB filename expansion.
What this chars are standing for? Should VDR simply remove nonprintable chars in the EPG info used for directory name generation?
Greetings, Bernd
Bernd Juraschek wrote:
Hi,
for some videos I got directory names containing control chars (I've found ^A and ^B). Sometimes this chars are confusing bash's TAB filename expansion.
What this chars are standing for?
VDR/recording.c:
tCharExchange CharExchange[] = { { '~', '/' }, { ' ', '_' }, { ''', '\x01' }, { '/', '\x02' }, { 0, 0 } };
Should VDR simply remove nonprintable chars in the EPG info used for directory name generation?
VDR needs to map the ' (single quote) and / (forward slash) to something else. I selected character codes 0x01 and 0x02, which don't seem to cause any trouble in VDR's operation. To be honest, bash's TAB filename expansion was none of my concern.
Klaus
On Tuesday 14 February 2006 20:47, Bernd Juraschek wrote:
Hi,
for some videos I got directory names containing control chars (I've found ^A and ^B). Sometimes this chars are confusing bash's TAB filename expansion.
What this chars are standing for? Should VDR simply remove nonprintable chars in the EPG info used for directory name generation?
I've seen similar things in the UK where we don't have accents, etc. For me, I think the problem comes from apostrophes in titles which end up as something like ^A as you've seen.
I've just found that I currently have a recording with such a name. ls shows the directory as: "Jonathan_Ross?_Asian_Invasion". If I try bash TAB-completion on this it comes up as: "Jonathan_Ross^A_Asian_Invasion". Sometimes, if I then TAB again to get the dated directory as well, it adds a second ^A and the 'cd' command or whatever will fail unless I go back and remove one of the ^A bits! I wouldn't be surprised if this behaviour was different depending on $LC_ALL, $LANGUAGE, etc.
I wondered about tackling this a while back and this is what I understand: the function cRecording::ExchangeChars swaps various 'odd' characters in the titles when filenames are generated, e.g. a space becomes an underscore. It looks like any apostrophes are changed into 0x01 for the filename (and then back again when displayed). All this works fine until your shell gets confused by it!
I'm not sure of a solution to this, apart from either using a different character from 0x01 or just removing them from recording names. 0x02 and 0x03 also are used for '/' and (vfat only) ':'.
Cheers,
Laz
-
Bernd Juraschek -
Klaus Schmidinger -
Laz