hubshell attachstring

hubfs [ -Dt ] [ -q bytequantity ] [ -l maxmsglen ] [ -b bytespersecond ] [ -i mininterval ] [ -r resettime ] [ -a address ] [ -m mountpoint ] [ -s srvname ]

The base behavior of hub srvname is bimodal, and will function as either a client or server depending on whether /srv/srvname exists. If no name is provided, hub will create or attach to a /srv named /srv/hubfs containing a persistent rc(1) session. Thus, the simplest possible model of use is:

hub

to start a hubfs hosted persistent rc(1) shell. Another invocation of

hub

from any window with access to that /srv will connect to it. The -b flag to hub backgrounds the initially created rc(1) instead of attaching to it. The -t flag starts the hubfs in trunc mode, which means clients will not be sent the previously buffered data upon connection.

Hubfs can be used to provide general purpose pipes locally or across a network, with some special features. Most notably, echoing freeze to the ctl file will change the behavior of the hub files from pipe-like with blocking reads to simple static files that can be viewed and edited with normal tools. Writing melt to ctl will restore pipe-like behavior and resume the normal flow of data.

While connected via a hubshell input beginning with a %symbol will be checked for matching command strings. These commands are used to create new subshells within the hubfs session and move between them. A distinctive feature is the ability for remote clients to share a local shell with other clients of the hubfs. The %local NAME command does this. The more traditional mode of starting new shells on the remote host is done with the %remote NAME command. Note that 'remote' is the machine hosting the shell you are connected to currently, and the active hubs must be running a shell, not another application. %detach terminates the hubshell and returns control to the user's original shell.

Hubfs options

The only mandatory option is a parameter to specify a srvname or mountpoint. The following parameters are not generally relevant or used for screen/tmux style usage, but are useful if hubfs is being used for irc-like chat service or audio streaming. The default size of a hubfile buffer is 777777 bytes, chosen to approximately match the scrollback buffer of a rio window. The -q bytequantity parameter sets this to a different size. For applications such as audio streaming, a buffer of several megabytes is probably preferable. The default maximum size of a single write is 666666 bytes. The -l maxmsglen parameter selects a different maximum message input size. By default, no rate-limiting of writes is applied, but can be activated by supplying any or all of the -b -i or -r parameters. -b bytespersec sets the maximum number of bytes per second that can be written, -i mininterval sets the minimum interval in nanoseconds between writes to the fs. There are 1000000000 (one billion) nanoseconds per second. The -r resettime parameter sets an interval in seconds after which the ratelimiting resets the timers. -D is for chatty9p debugging output, and the -t flag mentioned above means clients do not receive the previously buffered data when they connect.

start and connect to a new hubfs and post /srv/aug5

hub aug5

connects a new client to the rc shell started by the previous command

hub aug5

start and connects to new rc named rctwo within the aug5 hubfs

hub aug5 rctwo

Making new shells and moving in hubshell:

-all commands begin with '%' as first character-

%detach  # disconnect from attached shell

%remote NAME # start shell on remote machine

%local NAME # start shell on local machine shared to hubfs

%attach NAME # move to an existing hubfs shell

%err TIME, %in TIME, %out TIME # time in ms for delay loop

%status # basic hubfs connection info

%list # lc of connected hubfs hubs

%fear # paranoid mode, %calm to return to normal operation

%trunc # don't send buffered data, %notrunc reactivates

%echoes # turn on echo flush, %unecho to turn off

%fortun # turn on fortune flush, %unfort to deactivate

echo eof >/n/hubfs/ctl # send eof to all readers on all hubs

echo eof NAME >/n/hubfs/ctl # send eof to the named hub

echo freeze >/n/hubfs/ctl # freeze Hubs as static files

echo melt >/n/hubfs/ctl # resume normal flow of data

echo fear >/n/hubfs/ctl # paranoid, writers wait for readers

echo calm >/n/hubfs/ctl # resume non-paranoid mode

echo trunc >/n/hubfs/ctl # don't send buffered data

echo notrunc >/n/hubfs/ctl # send buffer to new clients

echo quit >/n/hubfs/ctl # kill the fs

In the standard mode of use for interactive rc shells, the synchronization between stdout and stderr is not maintained. The symptom is prompts appearing in seemingly the wrong place. To fix this, enter a command like %err 300 to set 300 milliseconds of delay before data from stderr is printed.

Because hubfs maintains static buffers and always allows clients to write to avoid loss of interactivity, slow readers may experience data loss while reading output larger than the size of the static buffer if the output was also transmitted fast enough to "wrap around" the location of the reader in the data buffer. The purpose of "paranoid" mode is to restrict the speed of writers if this is a concern. Another option is to make use of the rate-limiting options to throttle the speed of writes.

"Doug had for years and years, and he talked to us continually about it, a notion of interconnecting computers in grids, and arrays, very complex, and there were always problems in his proposals. That what you would type would be linear and what he wanted was three-dimensional, n-dimensional...I mean he wanted just topological connection of programs and to build programs with loops and and horrid things. He had such grandiose ideas and we were saying, the complexity you're generating just can't be fathomed. You don't sit down and you don't type these kind of connections together. And he persisted with the grandiose ideas where you get into Kirchoff's law problems...what happens if you have a feedback loop and every program doubles the number of characters, it reads one and writes two? It's got to go somewhere - synchronization - there's just no way to implement his ideas and we kept trying to pare him down and weed him down and get something useful and distill it. What was needed, was real ideas...and there were constant discussions all through this period, and it hit just one night, it just hit, and they went in instantly."

~Ken Thompson on UNIX pipes' origins

http://www.princeton.edu/~hos/mike/transcripts/thompson.htm