Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Bob Proulx Newsgroups: gnu.utils.bug Subject: Re: shar Date: Fri, 20 Mar 2020 19:00:44 -0600 Lines: 55 Approved: bug-gnu-utils@gnu.org Message-ID: References: <20200320184258524569738@bob.proulx.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1584752453 29294 209.51.188.17 (21 Mar 2020 01:00:53 GMT) X-Complaints-To: action@cs.stanford.edu Cc: "bug-gnu-utils@gnu.org" To: Ben White Envelope-to: bug-gnu-utils@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1584752444; bh=wBt44pFUT4YQQSTsPmA4br1D4PFG6lOVPfRScBQ0uq4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fEchbpZ96xeQJ14RE4ByFwqiQpDnTxsaNbkGlKyrDNqKLSurq9z4GXP2sSWzUPWGt QLTS8o0tbdglJ//1S45zsK4ueSEnDIKHX6U0sxY5LMLF61pxSfplyUixXFIkOrrpkQ NyJI88YpY2qQNzjrp8axJyCUcQR8X60HrjUI7WGImvLK+pET1+7RXTkMW+iLFFaw81 UmPyMmjsycUdrwbwKVXF3VLU1CarkqJluDjLOFjdDbK0ka2QFls34b0GV9fK/oZQa2 npOdFkVcWxQzrAevtUEMhxHpOFbqREGo7VOzowe8Ns347zp8CM7lUgs06oz9k099oK qlYKP0GO8nSvA== Mail-Followup-To: Ben White , "bug-gnu-utils@gnu.org" Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 X-BeenThere: bug-gnu-utils@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU utilities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <20200320184258524569738@bob.proulx.com> X-Mailman-Original-References: Xref: csiph.com gnu.utils.bug:2282 Ben White wrote: > Mail to bug-gnu-utils@gnu.org I am not the maintainer. But you are at the right place. :-) > The shar command is uuencoding some of the files in my archive, even > though I specified -text-files on the command line. All of the > files are all .cpp files. I suspect the reason for this behavior is > that some files have line length up to 288 characters. If I intentionally create a file with very long lines I do not recreate the behavior. Therefore it is likely something different. sh -c 'echo $(seq 1000)' > file1 wc file1 1 1000 3893 file1 ...characters out to 3893 on one line... shar file1 | grep uudecode shar: Saving file1 (text) sed 's/^X//' << 'SHAR_EOF' | uudecode && ...the file is uuencoded... shar --text-files file1 | grep uudecode shar: Saving file1 (text) ...the file is not uuencoded... I used an explicit shell so that the large arguments created would not increase the memory footprint of my command shell with the argument expansion. It would do it in the subshell, and then exit. This very long line did not trigger uuencode of the file. Therefore I suspect the problem is something different. I happen to be using shar version 4.15.2 from Debian with two Debian patches in this test. > Is there a way to force shar to never uuencode the files ? As far as I know --text-files is the way. Could you share with me one of the files that is triggering the uuencode behavior? Since I know it is a cpp file, you could email it to me directly and I won't share it further. In the meantime, what version of shar are you using? And what OS you are running upon? $ shar --version shar (GNU sharutils) 4.15.2 Copyright (C) 1994-2015 Free Software Foundation, Inc., all rights reserved. This is free software. It is licensed for use, modification and redistribution under the terms of the GNU General Public License, version 3 or later Please send bug reports to: Bob