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=3.0 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, T_SCC_BODY_TEXT_LINE autolearn=no 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 4413C2BD6E for ; Wed, 28 Aug 2024 16:30:25 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Aug 28 10:29:25 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1724855359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mFof89+755b0HZ0L88yPGfnt4ns3lNizAaFAVyJdPbY=; b=nu+Na27dsHmYP1r+O1hxdaE7++JqMUkL7VvFkzMAj5llPZQLP2+YcUo/3yQ2ltjh1oQ58x GMkQh5b32HVEawasQOwoKsyI8YlvQrV+f/4AIoJJTQcKL/t4196fIBR2GCv2F09qZFskKw TJ/i8Nb6p8h8f3IWi/87lviU7I/mlqg= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 9bec1a3b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 28 Aug 2024 09:29:19 -0500 (CDT) Message-ID: <378b3dc3-e759-46f2-87e8-01c25c0f1b56@posixcafe.org> Date: Wed, 28 Aug 2024 09:29:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <999fc991-e662-4a7c-8bda-a912c1b7bff0@posixcafe.org> <0b4d90f2-5e45-44b7-867f-53783e754f41@app.fastmail.com> Content-Language: en-US From: Jacob Moody In-Reply-To: <0b4d90f2-5e45-44b7-867f-53783e754f41@app.fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: CMS strategy Subject: Re: [9front] drawterm lib configuration Reply-To: 9front@9front.org Precedence: bulk On 8/28/24 03:30, Romano wrote: > I do not know why the image I attached is corrupted. Trying with a smaller image size. > > On Wed, Aug 28, 2024, at 1:15 AM, Romano wrote: >> Thanks for the feedback, moody. My inline explanations below. >> >> On Tue, Aug 27, 2024, at 3:05 PM, Jacob Moody wrote: >>> On 8/27/24 13:40, Romano wrote: >>>> I use drawterm from different OSes to connect to my >>>> 9front systems and noticed that there's a generic >>>> pattern that I usually take in modifying my lib/profile >>>> for different clients that I'm drawterm'ing from. >>>> I also noticed that the newuser(1) man page's >>>> presentation of what is generated for lib/profile was >>>> out-dated and not all architectures had underlying 'bin' >>>> directories created for the user. So I figured I'd take >>>> a stab at updating newuser(1) and its man page to have >>>> newuser also create a lib/drawterm directory, with >>>> lib/drawterm/default being the corresponding profile for >>>> when someone drawterm's in to the system. Here's a >>>> link to my attempt in case anyone finds it useful: >>>> >>>> http://only9fans.com/unobe/patches/4ac3a0224ed9d54818f858fba69c8e94f38f2c12/9front/2235c398fa9e7b48e0c84cda05c6994a14736e55.patch/raw >>> >>> I know this isn't a request to merge this in to 9front, but I still >>> wanted to comment on some things I noticed in your patch. >>> The whole lib/drawterm/* thing doesn't seem like it would be too useful >>> to me personally in general. >> >> It helps me setup my drawterm defaults based on what client I am >> dialing in from (e.g. work laptop, my wife's laptop, my macbook). I >> anticipate having more but also I don't assume it's useful for everyone. What defaults are you changing here? >> >>> diff c32dabd4853888f62f09a6d3f8e0deed4077b6a7 >>> 2235c398fa9e7b48e0c84cda05c6994a14736e55 >>> --- a/sys/lib/newuser >>> +++ b/sys/lib/newuser >>> @@ -1,5 +1,4 @@ >>> #!/bin/rc >>> - >>> user=`{cat /dev/user} >>> home=/usr/$user >>> if(test -f $home/lib/profile){ >>> >>> This seems like accidental noise that got in to your patch. >> >> I didn't see a point in the blank line. Most of our scripts have this blank line, it's style. >> >>> >>> @@ -8,10 +7,10 @@ >>> } >>> cd $home >>> x='$' >>> -mkdir bin bin/rc bin/mips bin/386 bin/amd64 bin/power bin/arm bin/arm64 >>> -mkdir lib tmp >>> +mkdir bin/^('' rc spim arm arm64 amd64 386 power power64 mips) >>> +mkdir lib lib/drawterm tmp >>> chmod +t tmp >>> -bind -qc /n/other/usr/$user/tmp $home/tmp >>> +if(test -d /n/other/usr/$user/tmp) bind -qc /n/other/usr/$user/tmp $home/tmp >>> bind -c $home/tmp /tmp >>> mail -c >>> auth/cron -c >>> @@ -22,38 +21,41 @@ >>> >>> You can use mkdir -p instead to clean up these calls, and remove this >>> bin/('') thing. >>> It'll read more naturally. >> >> Thanks! I had considered that but didn't know if I wanted to force >> directory creation and that's why it wasn't done before. So I opted for >> at least a list expansion. 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. >> >>> @@ -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. >> >>> case cpu >>> - bind /mnt/term/dev/cons /dev/cons >>> - bind -q /mnt/term/dev/consctl /dev/consctl >>> - >[2] /dev/null { >>> - cp /dev/sysname /mnt/term/dev/label >>> - if(wsys=`{cat /mnt/term/env/wsys} && ~ $x^#wsys 1) { >>> - wsys=/mnt/term^$x^wsys >>> - } >>> - if not { >>> - wsys=() >>> - } >>> - } >>> - bind -a /mnt/term/dev /dev >>> + # if rcpu or drawterm: >>> + if(test -d /mnt/term/dev){ >>> + bind /mnt/term/dev/cons /dev/cons >>> + bind -q /mnt/term/dev/consctl /dev/consctl >>> + >[2] /dev/null { >>> + cp /dev/sysname /mnt/term/dev/label >>> + if(wsys=`{cat /mnt/term/env/wsys} && ~ $x^#wsys 1) >>> + wsys=/mnt/term^$x^wsys >>> + if not >>> + wsys=() >>> + } >>> + bind -a /mnt/term/dev /dev >>> + } >>> prompt=('cpu% ' ' ') >>> fn cpu%{ $x^* } >>> - if(! test -e /mnt/term/dev/wsys){ >>> - # call from drawterm >>> - if(test -e /mnt/term/dev/secstore){ >>> - auth/factotum -n >>> - read -m /mnt/term/dev/secstore >/mnt/factotum/ctl >>> - echo >/mnt/term/dev/secstore >>> - } >>> - if not >>> - auth/factotum >>> >>> The reason this check is written this way is because drawterm will not >>> have a /mnt/term/dev on windows. >>> So your first check here will fail with a windows client. >> >> I was surpised by this. It just so happens that the Windows recovery >> USB stick (which cost $20) for an ideapad I got for $5 came in today. >> So I installed Windows 10 Home and downloaded drawterm.exe; I see a >> /mnt/term/dev directory (see the attached screenshot), and as I >> drawterm'd in, my patch works as I expected. Is it perhaps different >> for different versions of Windows? Does your drawterm.exe not provide a >> dev dir? 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.