Re: [9front] drawterm lib configuration

[Jacob Moody <moody@posixcafe.org>]

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.