[9front] wloc - rc doesn't work because of pid

[9front] wloc - rc doesn't work because of pid

[sirjofri]

Good morning,

> contains several window commands generated by wloc.

- rio(1)

However, wloc uses the window labels to construct the commands, and rc 
labels contain the pid by default. Thus it's impossible to restore 
existing rc windows without relabelling them manually before running 
wloc.

Imo using labels to reconstruct windows isn't a good design. The only way 
to accurately restore windows is by labelling the windows when running 
applications, therefore using the windows label as some kinda 'dump' 
place (like acme Dump/Load). This can conflict with user intentions for 
custom labels.

Restoring rc windows can currently only work by running a command 
beforehand, e. g. the label command or a shell script/program controlling 
the label. However, the label is also used for display in winwatch, which 
can cause issues with workflows (e. g. I use labels in winwatch to 
describe the namespace of that window, which breaks the workflow for 
wloc).

The only out-of-the-box-solution I can currently think of is, removing 
the pid from a default rc session label.

(If you don't want to read a different design idea, you can skip to the 
end at this point.)

If I were to design a better way around that, I'd probably give rio 
windows another file (dump) which can be controlled by an application and 
is used instead of the label. The dump line would be a complete command 
to partially restore the full session, including namespace, label, and 
potentially state.

A gridchat rc session could for example put the string

   rc -c 'label gridchat; 9fs net!chat.9p.zone!9999 /n/chat'

inside the dump file, which is then used by wloc to construct the line

   window -r x y a b rc -c 'label gridchat; 9fs ...'

... you get the idea.

The design would work, but would probably also break compatibility with 
other 9 systems. However, it would also work as an addition (don't use 
wloc, but name it differently, original 9 tools can just ignore the dump 
file).

sirjofri

Re: [9front] wloc - rc doesn't work because of pid

[umbraticus]

As the manpage says, it's just an aid to crafting a riostart;
how often are you using wloc?  As is seems good enough.
What if I just ran window with no args, then started myprog
in the new window manually? It's not in your dump thing now
but label probably does give a reasonable idea what's running.

Here's a similar script I use fairly often, to quickly access
another window's text, window, &c.:

for(i in `{walk -dn1,1 /dev/wsys}){
	echo -n $i^'/		# '
	cat $i/label
	echo
}

umbraticus

Re: [9front] wloc - rc doesn't work because of pid

[sirjofri]

As the man page states it, I'd expect to be able to use wloc to 
reconstruct the windows (not exactly the programs) I have open currently.

See this scenario:

I have an acme window open and an rc window. I run wloc > myriostart.

The next time I try to reconstruct that window layout with rio -i 
myriostart.

The result is, one acme window. No rc window, since it's impossible to 
run rc with a pid as an argument.

You can say it's a feature or a bug, whatever you want. Imo this way wloc 
is only partially reliable.

More things to reconsider: what if I relabel the acme window? It's still 
an acme window, but with a different name, and I get no windows since the 
label doesn't name a program.

What if I relabel the acme window with some existing program? For 
example, stats? I get a huge stats window and not an acme window at all.

What if I relabel my acme window to fshalt? 🤔😂 ... Ok that's probably 
your own fault then...

In the end, when using wloc and programs you download from anywhere else, 
always check the labels of your windows.

sirjofri

Re: [9front] wloc - rc doesn't work because of pid

[sirjofri]

One potential other solution for wloc: don't use the full label, but only 
the first token, which is likely a command without arguments.

This would fix the rc pid issue and still work the same as always. Of 
course you lose the ability to reconstruct your programs with arguments 
(e. g. filenames).

sirjofri

Re: [9front] wloc - rc doesn't work because of pid

[mkf9]

sirjofri wrote:
> One potential other solution for wloc: don't use the full label, but 
> only the first token, which is likely a command without arguments.
> 
> This would fix the rc pid issue and still work the same as always. Of 
> course you lose the ability to reconstruct your programs with arguments 
> (e. g. filenames).
> 
> sirjofri

i had following solution in my mind
if label shows a pid, check what binary? (using proc name?) it's 
running, usually it's rc, but some programs won't change label of 
default window's label.