[9fans] 9p and how can I know when a write is finished

[9fans] 9p and how can I know when a write is finished

[Gabriel Diaz]

Hello,

I'm not sure if I'm misunderstanding this but,
i need to write to a ctl file some commands,
so to parse them correctly i need the complete
command (commands file should be 10k or so, but
may be more).

How can I know when a write is finished to start
parsing the commands? (i mean, if occurs
that the write is done with multiple requests ).

Twrite tag[2] fid[4] offset[8] count[4] data[count]

Is there any special mark on those fields? what is
the man page i am missing?

thank you very much

gabi

Re: [9fans] 9p and how can I know when a write is finished

[Sape Mullender]

> Hello,
>
> I'm not sure if I'm misunderstanding this but,
> i need to write to a ctl file some commands,
> so to parse them correctly i need the complete
> command (commands file should be 10k or so, but
> may be more).
>
> How can I know when a write is finished to start
> parsing the commands? (i mean, if occurs
> that the write is done with multiple requests ).
>
> Twrite tag[2] fid[4] offset[8] count[4] data[count]
>
> Is there any special mark on those fields? what is
> the man page i am missing?

If you're writing a file server, look at the file servers that are there
to see what they look like.  ramfs is a nice and simple example.

If you send commands in a single write operation, they will
arrive in a single write operation.  read9pmsg(2)
gathers just the right number of bytes for you and convM2S(2)
converts the message to a C struct.

	Sape

[9fans] Re: 9p and how can I know when a write is finished

[Gabriel Diaz]

Hello

i see now, forgot what i said as i posted
too early.

thanks

gabi

Re: [9fans] 9p and how can I know when a write is finished

[Anselm R. Garbe]

On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:
> Hello,
>
> I'm not sure if I'm misunderstanding this but,
> i need to write to a ctl file some commands,
> so to parse them correctly i need the complete
> command (commands file should be 10k or so, but
> may be more).
>
> How can I know when a write is finished to start
> parsing the commands? (i mean, if occurs
> that the write is done with multiple requests ).
>
> Twrite tag[2] fid[4] offset[8] count[4] data[count]
>
> Is there any special mark on those fields? what is
> the man page i am missing?

As far as I understood, you wait until Tclunk.

Regards,
--
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361

Re: [9fans] 9p and how can I know when a write is finished

[uriel]

> On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:
>> Hello,
>>
>> I'm not sure if I'm misunderstanding this but,
>> i need to write to a ctl file some commands,
>> so to parse them correctly i need the complete
>> command (commands file should be 10k or so, but
>> may be more).
>>
>> How can I know when a write is finished to start
>> parsing the commands? (i mean, if occurs
>> that the write is done with multiple requests ).
>>
>> Twrite tag[2] fid[4] offset[8] count[4] data[count]
>>
>> Is there any special mark on those fields? what is
>> the man page i am missing?
>
> As far as I understood, you wait until Tclunk.
Wrong, the Tclunk is not warranteed to arrive any time soon.

Tclunk != close()

uriel

Re: [9fans] 9p and how can I know when a write is finished

[Anselm R. Garbe]

On Wed, Mar 01, 2006 at 04:20:27PM +0100, uriel@cat-v.org wrote:
> > On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:
> >> Twrite tag[2] fid[4] offset[8] count[4] data[count]
> >>
> >> Is there any special mark on those fields? what is
> >> the man page i am missing?
> >
> > As far as I understood, you wait until Tclunk.
> Wrong, the Tclunk is not warranteed to arrive any time soon.
>
> Tclunk != close()

How else do you want to decide? Waiting for a write with count=0
might work by policy, but is not specified (I dunno the
convenience libs of Plan 9), but I answered this as question of
the protocol and not of a specific implementation of convenience
libs. What might work is checking if count < iounit and guessing
that no Twrite will follow...
In the end you are on the safe side when waiting for Tclunk.

Regards,
--
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361

Re: [9fans] 9p and how can I know when a write is finished

[Gabriel Diaz]

Hello

what i see now, is that i should not expect
an end. i will use a control structure to be
able to "edit" the file and allow the file
behave as a normal file.

the functionality i want is somethin like:

% echo command > ctl
% ls
commandfile
% cat ctl
command
% rm commandfile
% cat ctl
% touch commandfile
% cat ctl
command-default

and to be able to acme ctl, put new changes
and recreate only the needed files. not all of them.
(not sure if i want this last complex thing, may be recreating the
files is cheaper)

what do you think?

gabi


On 3/1/06, Anselm R. Garbe <garbeam@gmail.com> wrote:
>
> On Wed, Mar 01, 2006 at 04:20:27PM +0100, uriel@cat-v.org wrote:
> > > On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:
> > >> Twrite tag[2] fid[4] offset[8] count[4] data[count]
> > >>
> > >> Is there any special mark on those fields? what is
> > >> the man page i am missing?
> > >
> > > As far as I understood, you wait until Tclunk.
> > Wrong, the Tclunk is not warranteed to arrive any time soon.
> >
> > Tclunk != close()
>
> How else do you want to decide? Waiting for a write with count=0
> might work by policy, but is not specified (I dunno the
> convenience libs of Plan 9), but I answered this as question of
> the protocol and not of a specific implementation of convenience
> libs. What might work is checking if count < iounit and guessing
> that no Twrite will follow...
> In the end you are on the safe side when waiting for Tclunk.
>
> Regards,
> --
>  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361
>
>

Re: [9fans] 9p and how can I know when a write is finished

[C H Forsyth]

>>Wrong, the Tclunk is not warranteed to arrive any time soon.
>>Tclunk != close()

> In the end you are on the safe side when waiting for Tclunk.

i think it's sad not to implement close [or equivalent] -> Tclunk in a timely way,
and indeed in an orderly manner (wrt the same client process),
at least for files, and especially for files with DMEXCL.

Re: [9fans] 9p and how can I know when a write is finished

[jmk]

On Wed Mar  1 10:57:01 EST 2006, forsyth@vitanuova.com wrote:
> >>Wrong, the Tclunk is not warranteed to arrive any time soon.
> >>Tclunk != close()
>
> > In the end you are on the safe side when waiting for Tclunk.
>
> i think it's sad not to implement close [or equivalent] -> Tclunk in a timely way,
> and indeed in an orderly manner (wrt the same client process),
> at least for files, and especially for files with DMEXCL.

The shadowy '9P Dubious Protocol Enhancement Committee' will
perhaps consider that at their next secret meeting.

Re: [9fans] 9p and how can I know when a write is finished

[Russ Cox]

> I'm not sure if I'm misunderstanding this but,
> i need to write to a ctl file some commands,
> so to parse them correctly i need the complete
> command (commands file should be 10k or so, but
> may be more).

Each write message looks logically separate, even if they are
all coming from a single write(2) system call.  If the data may
be 10k or more, I wouldn't even assume they're all from the same
system call, of course, and then there's not even any possibility
of a guarantee.

The convention in this case is to accumulate the writes for
a particular open fid in a buffer associated with that fid,
and then wait for the Tclunk.  This is sometimes unsatisfactory
because you might want to indicate that an error happened,
and Tclunk can't fail (and close(2) doesn't return -1 on real fds).
In wikifs I chose to allow a zero-length write at the end of a
sequence of writes to mean "okay, I'm done, do the processing
and return me an error if something goes wrong".  But if you
skip the zero-length write, wikifs will still do the processing
on Tclunk.  You just won't get any indication of errors in the
file you just wrote.

A better but more involved solution is to have a directory for
each active conversation (a la /net or /dev/draw) and in that
directory have a data file for the big stuff and a separate
control file for the little stuff.  In that case you might

	{
		cd /mnt/you/^`{cat}
		cp /tmp/blob data
		echo command >ctl
	} </mnt/you/clone

> Wrong, the Tclunk is not warranteed to arrive any time soon.

You are the one who is wrong.

The Tclunk for an open fid *is* guaranteed to be sent as soon as all
the client's references to that fid have been closed.

Arguably this is a detail of the client implementation, and a client
might choose to do otherwise, but every 9P client ever written (Plan 9,
Inferno, lib9pclient, v9fs, ...) does follow this rule.  To do otherwise
would cause problems not only with exclusive-use files but also
with file servers that give Tclunk special meaning, like:

	- in /net (like in the /mnt/you example above), network
	  connections are not fully given up until all the fids in the
	  corresponding directory are clunked.

	- in rio, once all the fids for a particular window are clunked,
	  the window is closed

	- in rio, writes to /dev/snarf are collected and only become the
	  new snarf buffer contents when the writing fid is clunked.

	- in plumber, writes to /mnt/plumb/rules are collected and only
	  become the new rules file when the writing fid is clunked.

	- in plumber, if no one has /mnt/plumb/quux open and there
	  is a message for the quux port, the plumber runs the start rule
	  associated with quux to handle the message.

	- in acme, an external program is assumed to be managing a
	  given window if it's event file is open.  if this fid were not clunked
	  in a timely manner when the file was closed, the window would
	  no longer respond to button 2 events like Del.

> Tclunk != close()

This is true, but not for the reason above.  If you consider:

	fd = open("/tmp/a", OREAD);
	fd2 = dup(fd, -1);
	close(fd);
	close(fd2);

then the Tclunk will be sent after the close(fd2), because that's the
last reference to that particular instance of the open fid.

Russ

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

uriel@cat-v.org wrote:
>>On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:

>>As far as I understood, you wait until Tclunk.
>
> Wrong, the Tclunk is not warranteed to arrive any time soon.
>
> Tclunk != close()


you guys are all confusing me. AFAIK, if you have written a plan 9
server, you have the standard Ye Olde Server Dispatche Functionne.

Said function, when it gets a Req with an op type of Twrite, calls the
appropriate server function, and replies.

I just finished writing another one of these (A GPS server ... fun!) and
it all Just Works.

So, I don't see the problem. Plan 9 packet sizes can be pretty big ---
much much bigger then the MTU on a network -- so the 9p server code
deals with it. When your Twrite gets called, it has the data.

ron

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

uriel@cat-v.org wrote:

> What is wrong with gpsfs(8)?

damn, another thing I missed. I will look at it, sigh. I should RTFM more.

Although, I may want my gpsfs to produce s-expressions.

w.r.t. the Twrite issue, I missed that point max size point. Oops.

ron

Re: [9fans] 9p and how can I know when a write is finished

[uriel]

> you guys are all confusing me. AFAIK, if you have written a plan 9
> server, you have the standard Ye Olde Server Dispatche Functionne.
>
> Said function, when it gets a Req with an op type of Twrite, calls the
> appropriate server function, and replies.
That is not the issue, the issue is that a single write() call can turn into various
Twrite operations.

> I just finished writing another one of these (A GPS server ... fun!) and
> it all Just Works.
What is wrong with gpsfs(8)?

> So, I don't see the problem. Plan 9 packet sizes can be pretty big ---
> much much bigger then the MTU on a network -- so the 9p server code
> deals with it. When your Twrite gets called, it has the data.
iounit also can be quite small, webfs for example is broken for even
slightly long URLs because it assumes they fit in a single Twrite, and
quite often they don't.

>From reading section 5 of the man pages, somehow I had (incorrectly)
understood that a Tclunk was not warranted to follow immediately a
close(), which seems to be only partially true as russ explained.

Maybe the bottom of clunk(5) should clarify that close() only
generates a Tclunk when it's the last reference to the fd is closed?

uriel

Re: [9fans] 9p and how can I know when a write is finished

[Gabriel Diaz]

Hello

Using "normal" files is quite easy to do like ramfs does,
but if you write commands to a file that should be parsed,
you should choose when will your parser run, just
in the fswrite call? if you receive multiple writes, may be
you end with a split command and your parser returning error.

The options people are saying are: wait for Tclunk or do special
write request like wikifs, or have a buffer that is managed with that
ctl.

and what i ask about is how the people handle this :)

Reading the responses i think i will try first buffering and parsing
when Tclunk.

gabi


On 3/1/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> uriel@cat-v.org wrote:
> >>On Wed, Mar 01, 2006 at 03:29:58PM +0100, Gabriel Diaz wrote:
>
> >>As far as I understood, you wait until Tclunk.
> >
> > Wrong, the Tclunk is not warranteed to arrive any time soon.
> >
> > Tclunk != close()
>
>
> you guys are all confusing me. AFAIK, if you have written a plan 9
> server, you have the standard Ye Olde Server Dispatche Functionne.
>
> Said function, when it gets a Req with an op type of Twrite, calls the
> appropriate server function, and replies.
>
> I just finished writing another one of these (A GPS server ... fun!) and
> it all Just Works.
>
> So, I don't see the problem. Plan 9 packet sizes can be pretty big ---
> much much bigger then the MTU on a network -- so the 9p server code
> deals with it. When your Twrite gets called, it has the data.
>
> ron
>

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

Gabriel Diaz wrote:
> Hello
>
> Using "normal" files is quite easy to do like ramfs does,
> but if you write commands to a file that should be parsed,
> you should choose when will your parser run, just
> in the fswrite call? if you receive multiple writes, may be
> you end with a split command and your parser returning error.

So you might need a state machine in the thing that handles write for
your ctl file.

If you're worried about conflicting writes from different writers, maybe
you can set the '1' attribute and then only one person gets to open it
and write to it?

We've had this problem in other circumstances (servers hanging off a TCP
line, integral commands not guaranteed) and it's pretty easy to handle
it. Also, take a look at, e.g., the TCL command interpreter -- same
exact problem: you get bits and pieces of a command, and you don't want
to fire until you get the whole thing. It's just a state machine approach.

ron

Re: [9fans] 9p and how can I know when a write is finished

[Russ Cox]

> iounit also can be quite small, webfs for example is broken for even
> slightly long URLs because it assumes they fit in a single Twrite, and
> quite often they don't.

You have 8k URLs?  Quite often?  No wonder you're always so angry.

Russ

Re: [9fans] 9p and how can I know when a write is finished

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You absolutely need 8k URLS - then you can encode your data, stick it
in the URL, and pass it to tinyURL.com for remote storage.

:-)


On 1-Mar-06, at 9:29 AM, Russ Cox wrote:

>> iounit also can be quite small, webfs for example is broken for even
>> slightly long URLs because it assumes they fit in a single Twrite,
>> and
>> quite often they don't.
>
> You have 8k URLs?  Quite often?  No wonder you're always so angry.
>
> Russ
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEBdy2pJeHo/Fbu1wRAgnwAKC9V0hTHKXsjpkd1Pwj+OpYQyr0igCg1dkU
3DuJKN8YRMVRQdtCXUv7vtM=
=UWCg
-----END PGP SIGNATURE-----

Re: [9fans] 9p and how can I know when a write is finished

[Skip Tavakkolian]

> The options people are saying are: wait for Tclunk or do special
> write request like wikifs, or have a buffer that is managed with that
> ctl.
>
> and what i ask about is how the people handle this :)
>
> Reading the responses i think i will try first buffering and parsing
> when Tclunk.

would it be unreasonable to give what's written to 'ctl' to
another thread that does the parsing based on seeing '\n'?

Re: [9fans] 9p and how can I know when a write is finished

[rog]

> If you're worried about conflicting writes from different writers, maybe
> you can set the '1' attribute and then only one person gets to open it
> and write to it?

it doesn't matter as long as every writer opens the file independently.
(the server then buffers on a per-fid basis).

BTW, the "perform action on clunk" choice has another potential
problem (besides lack of diagnostic feedback) - it forces the
file to be opened once for each control request, which implies
at least 3 more 9p requests each time. probably not an issue, but
might become one if doing many such requests over a network.

Re: [9fans] 9p and how can I know when a write is finished

[Latchesar Ionkov]

On Wed, Mar 01, 2006 at 06:21:00PM +0100, uriel@cat-v.org said:
> Maybe the bottom of clunk(5) should clarify that close() only
> generates a Tclunk when it's the last reference to the fd is closed?

Why should clunk(5) describe how an object defined outside of 9P protocol
use Tclunk?

	Lucho

Re: [9fans] 9p and how can I know when a write is finished

[uriel]

> On Wed, Mar 01, 2006 at 06:21:00PM +0100, uriel@cat-v.org said:
>> Maybe the bottom of clunk(5) should clarify that close() only
>> generates a Tclunk when it's the last reference to the fd is closed?
>
> Why should clunk(5) describe how an object defined outside of 9P protocol
> use Tclunk?
>
> 	Lucho
Because it already does so:

     ENTRY POINTS
          A clunk message is generated by close and indirectly by
          other actions such as failed open calls.

uriel

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

Paul Lalonde wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You absolutely need 8k URLS - then you can encode your data, stick it
> in the URL, and pass it to tinyURL.com for remote storage.

you know, I can't tell if you're joking. Thats' how bad it's gotten on
the net :)

ron

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

rog@vitanuova.com wrote:

> BTW, the "perform action on clunk" choice has another potential
> problem (besides lack of diagnostic feedback)

I can't think of a single good thing about using Tclunk to drive the ctl
state machine. Let's give that idea an indecent burial.

ron

Re: [9fans] 9p and how can I know when a write is finished

["Nils O. Selåsdal"]

Ronald G Minnich wrote:
> Paul Lalonde wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You absolutely need 8k URLS - then you can encode your data, stick it
>> in the URL, and pass it to tinyURL.com for remote storage.
>
> you know, I can't tell if you're joking. Thats' how bad it's gotten on
> the net :)
Todays quiz, joke or not a joke ?
http://www.msblabs.org/tinydisk/index.php

Re: [9fans] 9p and how can I know when a write is finished

[rog]

> I can't think of a single good thing about using Tclunk to drive the ctl
> state machine.

i can.  it's the simplest way of doing things, works smoothly with
existing stuff (e.g.  echo blah > ctl), and would be just fine if the
control request is never likely to fail, and performance isn't an
issue.

i've used russ's method of "zero-length write if you care about the
result" before, and that works well, but i have to say i usually just
ended up using cat or cp (i.e.  ignoring errors).

for another way, look at the way cdfs(4) lets you fixate disks.  it's
a little odd, but it works.

Re: [9fans] 9p and how can I know when a write is finished

[uriel]

> Paul Lalonde wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You absolutely need 8k URLS - then you can encode your data, stick it
>> in the URL, and pass it to tinyURL.com for remote storage.
>
> you know, I can't tell if you're joking. Thats' how bad it's gotten on
> the net :)
>
> ron

I wish this was a joke:

http://www.faqs.org/rfcs/rfc2397.html
http://www.mozilla.org/quality/networking/docs/aboutdata.html

And trust me, this is not even one of the worst parts of the web this days.

But that is not what I was referring to, fortunately data: urls are not
too common yet (but their popularity has been growing lately.)

We had problems with URLs >200 bytes long or so, I don't remember the
details, they are probably in the logs of #acme as fgb and me
investigated it some weeks ago.  Now that I think about it, it
certainly seems very strange how writes were split so early, I'm not
sure if we checked the exact iounit value, but it certainly seemed
strangely low to me.

uriel

Re: [9fans] 9p and how can I know when a write is finished

[Dave Eckhardt]

Ok, another suggestion for the "9P Dubious Protocol Enhancement Committee":

> Tclunk can't fail (and close(2) doesn't return -1 on real fds).

I agree that it doesn't make sense for Tclunk to fail in the
"no, you must continue making I/O requests against this object"
sense.

But any time there's asynchrony in the system Tclunk may end
up being the last time an error related to a previous operation
can be reported.  There isn't a "Tensure-all-bits-are-stable",
right?

I believe the Linux guys used to believe that VOP_CLOSE "couldn't
return errors" and defined the operation as void, and I don't think
they still do that.

Dave Eckhardt

Re: [9fans] 9p and how can I know when a write is finished

[rog]

> There isn't a "Tensure-all-bits-are-stable", right?

from stat(5):
	As a special case, if all the elements of the directory entry in a
	Twstat message are ``don't touch'' values, the server may interpret it
	as a request to guarantee that the contents of the associated file are
	committed to stable storage before the Rwstat message is returned.
	(Consider the message to mean, ``make the state of the file exactly
	what it claims to be.'')

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

rog@vitanuova.com wrote:
>>There isn't a "Tensure-all-bits-are-stable", right?
>
>
> from stat(5):
> 	As a special case, if all the elements of the directory entry in a
> 	Twstat message are ``don't touch'' values, the server may interpret it
> 	as a request to guarantee that the contents of the associated file are
> 	committed to stable storage before the Rwstat message is returned.
> 	(Consider the message to mean, ``make the state of the file exactly
> 	what it claims to be.'')
>

hmm. this is a Tsync by another name, to me ...

ron

Re: [9fans] 9p and how can I know when a write is finished

[erik quanstrom]

the great thing about standards is there are so many to ignore.

- erik

uriel@cat-v.org writes

|
| > Paul Lalonde wrote:
| >> -----BEGIN PGP SIGNED MESSAGE-----
| >> Hash: SHA1
| >>
| >> You absolutely need 8k URLS - then you can encode your data, stick it
| >> in the URL, and pass it to tinyURL.com for remote storage.
| >
| > you know, I can't tell if you're joking. Thats' how bad it's gotten on
| > the net :)
| >
| > ron
|
| I wish this was a joke:
|
| http://www.faqs.org/rfcs/rfc2397.html
| http://www.mozilla.org/quality/networking/docs/aboutdata.html
|
| And trust me, this is not even one of the worst parts of the web this days.
|
| But that is not what I was referring to, fortunately data: urls are not
| too common yet (but their popularity has been growing lately.)
|
| We had problems with URLs >200 bytes long or so, I don't remember the
| details, they are probably in the logs of #acme as fgb and me
| investigated it some weeks ago.  Now that I think about it, it
| certainly seems very strange how writes were split so early, I'm not
| sure if we checked the exact iounit value, but it certainly seemed
| strangely low to me.
|
| uriel

Re: [9fans] 9p and how can I know when a write is finished

[uriel]

> uriel@cat-v.org wrote:
>
>> What is wrong with gpsfs(8)?
>
> damn, another thing I missed. I will look at it, sigh. I should RTFM more.

It's not surprising almost no one has noticed about it, the only
application that I know that uses it(EFIS) remains unreleased for
unknown reasons despite my repeated requests.  *sigh*

Oh, and the man page index doesn't contain any reference to gpsfs(8)

Any reason why /sys/lib/man/lookman/mkindex is not run automatically?
There seems to be quite a few things missing from the index.  (The
comment at the bottom of man(1) about lack of automatic way of
keeping indexes uptodate can probably be removed.)


> Although, I may want my gpsfs to produce s-expressions.

Oh, yea, because s-expressions are so much easier to parse with awk...
I think we should replace /adm/users to use s-expressions too, and
/proc/$pid/ns should also be s-expressions!  And next we replace rc
with a scheme interpreter...

I love scheme, and s-expressions are a billion times better than XML
will ever be, but I'm starting to suspect s-expressions fanboys are
not too different from XML zealots and think s-expressions should be
used for everything everywhere.

S-expressions are not much better than XML when dealing with them from
a Unix/Plan 9 shell, and I can think of very few, if any, cases where
they might be justified, specially having in mind that the file system
already can provide a hierarchical structure.

uriel

Re: [9fans] 9p and how can I know when a write is finished

[Ronald G Minnich]

uriel@cat-v.org wrote:
> I can think of very few, if any, cases where
> they might be justified,

well, I already knew that :-)

ron

Re: [9fans] 9p and how can I know when a write is finished

[David Leimbach]

> Oh, yea, because s-expressions are so much easier to parse with awk...
> I think we should replace /adm/users to use s-expressions too, and
> /proc/$pid/ns should also be s-expressions!  And next we replace rc
> with a scheme interpreter...

Someone added XML to GNU Awk by the way....  After working with XSLT
for a while I was seriously itching for "xawk".

https://sourceforge.net/project/showfiles.php?group_id=133165

For some of us forced to deal with XML, this is a nice extension and
keeps us out of XSLT processing for a bit longer.

Dave