9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Romano <me+unobe@fallglow.com>
To: 9front@9front.org
Subject: Re: [9front] drawterm lib configuration
Date: Wed, 28 Aug 2024 01:30:32 -0700	[thread overview]
Message-ID: <0b4d90f2-5e45-44b7-867f-53783e754f41@app.fastmail.com> (raw)
In-Reply-To: <dcb513eb-3ec9-45f0-a115-a62e79f8dfb5@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]

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.
>
>> 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.
>
>>
>> @@ -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.
>
>> @@ -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.
>
>>  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?
> Attachments:
> * IMG_5538.jpeg

[-- Attachment #2: File1.png --]
[-- Type: image/png, Size: 526149 bytes --]

  reply	other threads:[~2024-08-28  8:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 18:40 Romano
2024-08-27 22:05 ` Jacob Moody
2024-08-28  8:15   ` Romano
2024-08-28  8:30     ` Romano [this message]
2024-08-28 14:29       ` Jacob Moody
2024-08-28 16:55         ` Romano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b4d90f2-5e45-44b7-867f-53783e754f41@app.fastmail.com \
    --to=me+unobe@fallglow.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).