From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OFeCI-0003Ty-RW for garchives@archives.gentoo.org; Sat, 22 May 2010 02:12:18 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D4DABE092B; Sat, 22 May 2010 02:11:55 +0000 (UTC) Received: from wlym.com (wlym.com [66.135.63.43]) by pigeon.gentoo.org (Postfix) with ESMTP id A435EE092B for ; Sat, 22 May 2010 02:11:55 +0000 (UTC) Received: from ccs.covici.com (pool-96-247-205-104.clppva.fios.verizon.net [96.247.205.104]) (authenticated bits=128) by wlym.com (8.14.3/8.14.3/Debian-5) with ESMTP id o4M285OD023019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 May 2010 21:08:07 -0500 Received: from ccs.covici.com (localhost [127.0.0.1]) by ccs.covici.com (8.14.4/8.14.4) with ESMTP id o4M2BnwR016847 for ; Fri, 21 May 2010 22:11:52 -0400 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] xargs and rm funkiness In-reply-to: <201005212149.49715.ddjones@riddlemaster.org> References: <201005212149.49715.ddjones@riddlemaster.org> Comments: In-reply-to Daniel D Jones message dated "Fri, 21 May 2010 21:49:49 -0400." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Fri, 21 May 2010 22:11:49 -0400 Message-ID: <16845.1274494309@ccs.covici.com> From: covici@ccs.covici.com Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: 14439cb9-36a3-4a37-8eb3-d90832617c77 X-Archives-Hash: b5e2e2a980a6c68e3ff601b21b9a672e Daniel D Jones wrote: > Running the command: > > find -name *.ext | xargs -0 rm > > I get the result: > > rm: cannot remove `Long File Name One.ext\nLong File Name Two.ext\nLong File > Name Three.ext\n': File name too long. > > (The actual list is much longer than this, of course, or I wouldn't be using > xargs.) For some reason, the \n isn't being recognized as a separator but > rather as a part of a single long file name. Don't think $IFS would affect a > command like rm but it doesn't appear to be the issue: > > ddjones@merlin ~ $ set | grep IFS > IFS=$' \t\n' > > I don't see any other ser variable which looks like a likely candidate to > cause the behavior. Anyone have a clue what's going on? Why do you have -0 -- this replaces the \n's with a null character -- is that what you want? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com