Hi Denys ! >> For what it's worth the users with this problem were unable to >> remove the files using wildcards. For example, one user had a >> file named: >> >> På hjul.mkv >> >> ls P* displayed the file. >> rm P* returned the error "can't remove 'På Hjul.mkv': No such >> file or directory" > >I have hard time believing this. >Wildcard expansion is done by the shell, not by ls and rm. > >IOW: ls and rm see exactly the same expanded names. > >Since they don't mangle the names in any way >(e.g. no UTF-8 decoding) before feeding them to system calls, >it should work.
I know this problem very well. It happens about every few month, that I get a ZIP packaged file from a Windows system. As the maintainer is a bit stupid, he can't manage to avoid foreign characters and I end up with unusual file names after unzip. Most likely they can be handled with wildcards (especially ?), but sometimes it gets a bit tricky to access those files, as they contain control or unprintable characters. In that case you need to know the exact length and position to enter question marks in file name. If you do a rm -i * it fails. Not due to name mangling in Busybox, but due to name mangling in file system drivers of the kernel (especially on fat file systems - like USB sticks or flash based disks). Therefore this is not a Busybox related problem, it's a general name handling problem when intermixing file systems and different charsets / code pages. It does not depend on a special Busybox version, I had the same problem even 10 years ago (complete different versions of kernel/lib/programs). -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
