From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chet Ramey Subject: bug#22354: Hash-bang line length Date: Wed, 13 Jan 2016 11:21:10 -0500 Message-ID: <56967976.2080908__30112.6904473223$1452710392$gmane$org@case.edu> References: <87lh7t7p4w.fsf@gnu.org> <20160113131902.GU27325@eeg.ccf.org> <87y4bt60zb.fsf@gnu.org> Reply-To: chet.ramey@case.edu Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJOBS-0002Qe-6r for bug-guix@gnu.org; Wed, 13 Jan 2016 11:22:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJOBO-0006Ab-2e for bug-guix@gnu.org; Wed, 13 Jan 2016 11:22:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:60220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJOBN-0006AX-Vk for bug-guix@gnu.org; Wed, 13 Jan 2016 11:22:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aJOBN-0002fr-TM for bug-guix@gnu.org; Wed, 13 Jan 2016 11:22:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87y4bt60zb.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Greg Wooledge Cc: 22354@debbugs.gnu.org, bug-bash@gnu.org, chet.ramey@case.edu On 1/13/16 8:52 AM, Ludovic Courtès wrote: > Greg Wooledge skribis: > >> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote: >>> Hello, >>> >>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from >>> the hash-bang line. This is less than the already-small 128-byte limit >>> in the Linux kernel¹ and can quite easily be hit². >> >> That's actually much bigger than one expects for shebang handling on >> any traditional Unix system. > > Sure, but the fact that it’s smaller than that of the kernel Linux is > problematic: when a hash-bang line > 127 chars is encountered, ‘execve’ > fails with ENOENT, so Bash’s fallback code is executed, fails as well, No. Since the execve fails with ENOENT, bash just prints an error message. > but it prints a misleading error message with an even more truncated > hash-bang line. Again, it's only a cosmetic issue. I don't have a problem with increasing the buffer size, but let's not pretend it's anything but that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/