From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Sat May 16 16:30:46 EDT 2020 Message-ID: <82412A1ACD62CDC4DB0267615A344641@felloff.net> Date: Sat, 16 May 2020 22:30:36 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] [PATCH] rio: add -label wctl param; improve window(1) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: RESTful general-purpose STM controller > It's not an issue per se, but it seems we are only doing it the > roundabout way because of wanting to label the new window while missing > the -label parameter to do so. We also do the environment cleanup, but > this only affects the -m case so it can be moved there. yeah. sorry. i agree it can be simplified. > I'd argue that the label is a window property just like the others we > are already setting through the 'new' wctl. I see no reason why it > should be handled specially from the rest, or alternatively why other > parameters shouldn't be set in a similar fashion by writing to /dev/wctl > in new window's namespace. maybe, but parsewctlmsg() in this form is not up to the task. you can't have labels with spaces in them for example. i said -cd has the same issue. if you have a directory that has a space in it you'r fucked. > Yes, the field parser is janky and could be helped with a rewrite in > terms of getfields(2). I can do it independently of this other stuff. ok. -- cinap