From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2efe70578a028bec7b9068c6c9be849e@terzarima.net> From: Charles Forsyth Date: Tue, 14 Oct 2008 14:15:15 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-levwkmshgkeykjwzhztehwbtyk" Subject: Re: [9fans] several things Topicbox-Message-UUID: 1e1cbdd0-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-levwkmshgkeykjwzhztehwbtyk Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit fd2path should probably complain if the buffer is too small. i'm surprised at any actual name longer than 512 (or even 256), not so much for plan 9, but because linux systems still seem to have that tiny TTY limit on the size of an input line, or it did the last time i tried to use the mouse to snarf and send a command line printed by make. --upas-levwkmshgkeykjwzhztehwbtyk Content-Type: message/rfc822 Content-Disposition: inline Received: from gouda.swtch.com ([67.207.142.3]) by lavoro; Tue Oct 14 13:33:29 BST 2008 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1Kpiuj-0005MT-66; Tue, 14 Oct 2008 12:22:13 +0000 Received: from ey-out-1920.google.com ([74.125.78.148]) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from ) id 1Kpiuh-0005MO-KP for 9fans@9fans.net; Tue, 14 Oct 2008 12:22:11 +0000 Received: by ey-out-1920.google.com with SMTP id 4so747365eyg.36 for <9fans@9fans.net>; Tue, 14 Oct 2008 05:22:10 -0700 (PDT) Received: by 10.86.70.3 with SMTP id s3mr6668941fga.50.1223986930375; Tue, 14 Oct 2008 05:22:10 -0700 (PDT) Received: by 10.86.51.7 with HTTP; Tue, 14 Oct 2008 05:22:10 -0700 (PDT) Message-ID: Date: Tue, 14 Oct 2008 15:22:10 +0300 From: Yaroslav To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26c1814ccfc8559a96987385a144c4e7@quanstro.net> Subject: Re: [9fans] several things X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+forsyth=terzarima.net@9fans.net > But at least it means that the 'pwd' function returns a wrong answer > _without_warning_ when the path is longer. I tried it. This is not a nice > thing. Are these limitations listed in some document? The pwd(1) utility has this limitation for simplicity. The getwd(2) function and fd2path(2) syscall can work on arbitrary-sized buffers. So, to overcome the limit, you have few choices: 1) modify the pwd.c to allocate more memory; or 2) bind not-so-long parts of your path to /n/something to construct a namespace with shorter absolute paths; or 3) blame the tree holders. -- Best regards, Yaroslav. --upas-levwkmshgkeykjwzhztehwbtyk--