From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id DDD692B66B for ; Wed, 28 Aug 2024 18:57:00 +0200 (CEST) Received: from pb-smtp21.pobox.com ([173.228.157.53]) by 9front; Wed Aug 28 12:56:00 -0400 2024 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id C45E53160D for <9front@9front.org>; Wed, 28 Aug 2024 12:55:57 -0400 (EDT) (envelope-from me+unobe@fallglow.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :date:from:to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding; s=sasl; bh=Ec2VqVwdnEd1jsvq59Fjws+IZ zfe1FXlhsNwna+vfJU=; b=Bd3jr5NkQKo4EUTU24zhrT4pvjg1+ESAMs+Wt9j9k kKlTI4sYku7pplM3fD/MGM0LkRUuA4v+Et4E/BFvkIPYcHGWjO4iIXbOu3LZmmKR akJbanU+UNjMGVPyUHWgW/bfYJKPm3I3E94hW4p5/HTAlg/jO0jAbDnjsNX3Ardt +k= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id BD7193160C for <9front@9front.org>; Wed, 28 Aug 2024 12:55:57 -0400 (EDT) (envelope-from me+unobe@fallglow.com) Received: from strider.localdomain (unknown [68.190.196.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 0D6BC315EA for <9front@9front.org>; Wed, 28 Aug 2024 12:55:54 -0400 (EDT) (envelope-from me+unobe@fallglow.com) Message-ID: <4DD9E1C4F82182303A7893CB307F3FBF@smtp.pobox.com> Date: Wed, 28 Aug 2024 09:55:51 -0700 From: Romano To: 9front@9front.org In-Reply-To: <378b3dc3-e759-46f2-87e8-01c25c0f1b56@posixcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 636AC274-655E-11EF-8D60-E92ED1CD468F-09620299!pb-smtp21.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ORM scripting package base rails Subject: Re: [9front] drawterm lib configuration Reply-To: 9front@9front.org Precedence: bulk On Wed Aug 28 07:31:20 -0700 2024, moody@posixcafe.org wrote: > What defaults are you changing here? Setting up different plumbing rules, different fonts (remember that bad patch for rio border size?), certain mounts. For example, when I drawterm from a mac I use osascript to open a new tab for web links, and open any docx files on the Mac. I also create a 9pfs mount (as explained on the wiki) to browse files using the Finder, if I prefer. > Most of our scripts have this blank line, it's style. Thanks for pointing that out. I see 77/135 of the scripts in /bin/rc have a second blank line, so 57% overall: cpu% { for (f in `{walk -f /rc/bin}) { echo `{sed 2q $f | tail -1} } } | sort | uniq -c | sort -r | sed 4q 77 25 rfork e 3 rfork en 2 if(~ $#* 3){ cpu% ls /rc/bin | wc -l 135 This isn't comprehensive by any means, but just a directory I knew had a lot of system rc scripts. For comparison, /bin/git directory (like /sys/lib/newuser) isn't included in the numbers above: cpu% { for (f in `{walk -f /bin/git}) { echo `{sed 2q $f | tail -1} } } | sort | uniq -c | sort -r | sed 3q 8 rfork ne 5 rfork en 3 In your experience, is calling rfork on the second line an exception to that style? If so, that would make about 78% of the scripts in /rc/bin conform to the style. But removing the '| sed 4q' at the end, you'd also see quite a few first lines being explanatory comments of what the script does, and about a dozen that just call exec. I haven't checked out a Plan 9's 4th edition or previous edition to compare to see if it has been newer style, or just always been a hodge-podge. Regardless, it's good for me to be aware of that: thank you. > What do you mean "forcing directory creation" you're calling mkdir, > you're creating directories. The two calls with -p or not with your > ordering are equivalent. Forcing intermediate directory creation, so really the 'bin' dir. This just reflected how the long-form was before my patch: it didn't use -p. I didn't know if there was a good reason for that, and thought it might have been for some esoteric but valid reason related to creating bin first, before its subdirectories. So I decided to write it without -p. > >>> @@ -22,38 +21,41 @@ > >>> font=/lib/font/bit/vga/unicode.font > >>> switch($x^service){ > >>> case terminal > >>> - webcookies > >>> - webfs > >>> - plumber > >>> echo -n accelerated > '#m/mousectl' > >>> echo -n 'res 3' > '#m/mousectl' > >>> prompt=('term% ' ' ') > >>> fn term%{ $x^* } > >>> + webcookies > >>> + webfs > >>> + plumber > >>> rio > >>> > >>> What does moving this around achieve? > >> > >> I didn't think it was foolish to have consistency with the other case > >> (cpu) to have those run at the end. I didn't see the point of having > >> them before those other commands. > > The point is to avoid churn, but I'm bikeshedding. I'm not sure it's bikeshedding here. My perspective is that a script should not do the same thing in a different order unless called for. I was trying to determine why the first three calls were separated from the last, when that isn't the case for cpu. I assume I will read this script again, and so considered it a benefit for the human reader to consolidate the calls as is done in the cpu case. > Right, drawterm does add it's own /dev/ to the root before exposing the > namesapce to the remote system so you'll see drawterm's /dev. > My recollection of the ordering was wrong and in retrospect doesn't make sense. > > That first check is just checking to see if we should make use of the /mnt/term/dev anyway, > so it seems fine to have that be the check there. *Whew*, well I'm glad that was one less thing I had possibly fumbled! Thanks again for the feedback, moody.