I have some problems with the filename. I want to transmit all the filenames by xml. But I have some problems with a special charvalue.
For Example: @Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
This is a problem because ^A is an alias for 0x01 which I can't return in xml.
My current version is 1.3.38. Maybe there has somethink changed.
Best regards Patrick
Patrick Fischer wrote:
I have some problems with the filename. I want to transmit all the filenames by xml. But I have some problems with a special charvalue.
For Example: @Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
This is a problem because ^A is an alias for 0x01 which I can't return in xml.
My current version is 1.3.38. Maybe there has somethink changed.
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
Klaus
Klaus Schmidinger wrote:
Patrick Fischer wrote:
I have some problems with the filename. I want to transmit all the filenames by xml. But I have some problems with a special charvalue.
For Example: @Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
This is a problem because ^A is an alias for 0x01 which I can't return in xml.
My current version is 1.3.38. Maybe there has somethink changed.
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
Klaus
Wouldn't it be easier if the filename contains NO "critical" chars and you put the displayed recordingname into the info.vdr file?
For me it is now impossible to transmit the correct filename over xml. xml don't allow 0x01 and I can't return the value.
Patrick
Patrick Fischer wrote:
Klaus Schmidinger wrote:
Patrick Fischer wrote:
I have some problems with the filename. I want to transmit all the filenames by xml. But I have some problems with a special charvalue.
For Example: @Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
This is a problem because ^A is an alias for 0x01 which I can't return in xml.
My current version is 1.3.38. Maybe there has somethink changed.
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
Klaus
Wouldn't it be easier if the filename contains NO "critical" chars and you put the displayed recordingname into the info.vdr file?
For me it is now impossible to transmit the correct filename over xml. xml don't allow 0x01 and I can't return the value.
Patrick
You could convert the 0x01 to a single quote when going to XML.
Klaus
Klaus Schmidinger wrote:
Patrick Fischer wrote:
@Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
This is only true in classic mode. In VFAT-mode, unsafe characters like this are mapped to literal ascii codes, in this case '#27'.
Using ASCII control chars (0x01 alias SOH for ', 0x02 alias STX for /) in file names doesn't sound like a good idea to me anyway. Wouldn't it be better to use '#27' and '#2F' (and consequently '#23' for #) in non-VFAT mode too?
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
Patrick Fischer wrote:
@Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
This is only true in classic mode. In VFAT-mode, unsafe characters like this are mapped to literal ascii codes, in this case '#27'.
Using ASCII control chars (0x01 alias SOH for ', 0x02 alias STX for /) in file names doesn't sound like a good idea to me anyway. Wouldn't it be better to use '#27' and '#2F' (and consequently '#23' for #) in non-VFAT mode too?
Cheers,
Udo
I've now made it so that in "normal" mode (non-VFAT) the single quote is not mapped any more (IIRC I thought that this might be necessary for external commands, but with strescape() and "..." this works just fine). The '/' and '~' are swapped between internal and external representation, so that no more "control" characters are used.
For backwards compatibility 0x01, 0x02 and 0x03 are still recognized.
Please give the attached patch a try.
Klaus
Klaus Schmidinger wrote:
Udo Richter wrote:
Klaus Schmidinger wrote:
Patrick Fischer wrote:
@Ripley's unglaubliche Welt will be saved as (only shown if I pipe "ll . > out.txt" and look at the file or by using xterm) @Ripley^As_unglaubliche_Welt
The single quote character is mapped to 0x01 so that in shell script it is guaranteed that no recording name contains such a character, and you can always be sure that enclosing a recording name in single quotes will work.
This is only true in classic mode. In VFAT-mode, unsafe characters like this are mapped to literal ascii codes, in this case '#27'.
Using ASCII control chars (0x01 alias SOH for ', 0x02 alias STX for /) in file names doesn't sound like a good idea to me anyway. Wouldn't it be better to use '#27' and '#2F' (and consequently '#23' for #) in non-VFAT mode too?
Cheers,
Udo
I've now made it so that in "normal" mode (non-VFAT) the single quote is not mapped any more (IIRC I thought that this might be necessary for external commands, but with strescape() and "..." this works just fine). The '/' and '~' are swapped between internal and external representation, so that no more "control" characters are used.
For backwards compatibility 0x01, 0x02 and 0x03 are still recognized.
Please give the attached patch a try.
Klaus
Well, my previous patch was actually much longer than necessary. That's because originally I had followed that path of actually en-/decoding these characters, but then I realized that this might cause trouble with existing recording names that already contain an unescaped '#'. Now I realized that a much smaller patch should do the trick just as well, so here's a second try.
Klaus
-
Klaus Schmidinger -
Patrick Fischer -
Udo Richter