I have a big playlist in .pls format (created with deadbeef playing software) which also contains some badly-encoded strings. Whether this is a bug in deadbeef or one of its plugins does not really interest me, though, since I just want to cut off from a certain position to the end of the line using sed.However, this is easier than it looks at first sight, since sed will instantly interrupt parsing once it hits a character it deems invalid:$ cat archives.pls | grep --perl-regexp Lika.*rar.*02rar:///home/andy/audio_compressed/world/ru/Lika Star - Ya (RUS 2001).rar:2001- /02 .mp3This is the original line, unmodified. Now let's try sed on it, to extract the path (note: this is for a script I'm almost finished with to check for dead audio files in the directory tree, i. e. those that do no longer exist) $ cat archives.pls | grep --perl-regexp Lika.*rar.*02 | sed -e 's/^\(zip\|rar\|7z\):\/\///' -e 's/\(\.\(zip\|rar\|7z\)\):.*/\1/' /home/andy/audio_compressed/world/ru/Lika Star - Ya (RUS 2001).rar/02 .mp3Ugh. This obviously did not work, though the regular expression is definitely correct (since it can be proved to work fine with so-called valid characters). The rar actually comes from a contraction of originally rar:2001- , which indicates that sed parsed from the colon via the 2001- to the blank, then stopped abruptly at the invalid  character.Still, there is the question left why doesn't sed just ignore what encoding it is and parses anyway? I mean, we want everything to be cut off after the colon following the rar, so it ought to be safe to assume that .* does definitely stand for any character?NOTE: Please refrain from seemingly elegant solutions using cut in your answers. Been there, done that. Instead, you had better consider that we're on a UNIX-type OS and we may even legitimately use strange file names that involve artists that originally spell :wumpscut: or the like. In other words, there might be a colon something in-between as well, which is why it would not be a good idea to statically cut off at the first colon we come across after the (zip|rar|7z)://.
How can I force sed to continue parsing when it hits an invalid character?
sed;character encoding;special characters