Argument list too long while copying

2012-08-23 Thread Jan Stary
On current/amd64 I created a MSDOS filesystem on a CF card inserted into a USB card reader # newfs_msdos -F 32 -L SHERLOCK sd3i and tried to copy some files to it # mount /dev/sd3i /mnt # cp * /mnt cp: /mnt/202.the-hounds-of-baskerville.avi: Argument

Re: Argument list too long while copying

2012-08-23 Thread Ted Unangst
On Thu, Aug 23, 2012 at 21:17, Jan Stary wrote: On current/amd64 I created a MSDOS filesystem on a CF card inserted into a USB card reader # cp * /mnt cp: /mnt/202.the-hounds-of-baskerville.avi: Argument list too long cp: /mnt/201.a-scandal-in-belgravia.avi: Argument list too long cp:

Re: Small change to let mg handle localized characters

2012-08-23 Thread Geoff Steckel
On 08/23/2012 03:50 PM, Stefan Sperling wrote: On Thu, Aug 23, 2012 at 08:58:53PM +0200, Eivind Evensen wrote: Since version 1.10 of lib/libc/gen/ctype_.c, I've been unable to use localized characters in mg properly (they're printed as an octal value only). I've been using the below change to

Re: Small change to let mg handle localized characters

2012-08-23 Thread Stefan Sperling
On Thu, Aug 23, 2012 at 05:32:51PM -0400, Geoff Steckel wrote: Using iconv in an editor is EXTREMELY dangerous without complex precautions. Given a file containing characters not valid in the current locale, it will at minimum prevent viewing the file. An editor needs to convert between

Re: Small change to let mg handle localized characters

2012-08-23 Thread Geoff Steckel
On 08/23/2012 06:55 PM, Stefan Sperling wrote: On Thu, Aug 23, 2012 at 05:32:51PM -0400, Geoff Steckel wrote: Using iconv in an editor is EXTREMELY dangerous without complex precautions. Given a file containing characters not valid in the current locale, it will at minimum prevent viewing the

Re: Small change to let mg handle localized characters

2012-08-23 Thread Mike Belopuhov
On Fri, Aug 24, 2012 at 12:55 AM, Stefan Sperling s...@openbsd.org wrote: For some bizarre reason emacs links to libossaudio instead ;) yeah, an sndio backend is yet to be written... another reason to migrate to the superior pulse-audio framework!