🚀 go-pugleaf

In article <8812022227.AA08886@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>	Right.  NULL: *does* work.  But let me qualify your statement
>just a little.  Not only does it have to be a *valid* device-handler,
>it must also accept Open("*", 1006) IN ALL CASES!  That is, you cannot
>set pr_ConsoleDevice to a filesystem handler because Open("*",1006)
>will fail if "*" is already open!

Unfortunately it's quite unusual that handlers recognized "*", (and this
is due to lack of information in the system docs no doubt), but in many
cases this is not a problem.
When the handler receives an "open"-packet, (i.e. 1005 or 1006), Arg3
is a BSTR containing the "file specification". It can be "DF0:foo" or
"AUX:" or "*" or whatever.
"*" is indeed different from the others since that name is not in the form
"device:name or "volume:name", it's just "*".

If the handler doesn't care what name you pass it (null: doesn't) it will
accept "*" as well as all other possible file names. That is ok as long
as it can handle *any* number of Open()s from *anybody*. And that
INCLUDES any numbers of Open()s for WRITING.
You see that writing is the main issue here, since two persons cannot
normaly write to the same file. But with "*" it is different
because of the "console" nature of this file.

The "*" file can be used both as input (copy * to foo) or as output
(copy foo to *). But mostly it is used as an output file: 
  * as stderr in C-programs
  * as default output for a program started with the Run command

In the case of output you *must* be able to open "*" as MANY TIMES
AS YOU WAN'T.

In the case of input you have to make a choice of two possibilities:
  1) Let everybody who opens "*" read from the file, and don't care
     in which order the different persons get their input.
     (this is a situation that must be experienced to be fully appreciated :-)
  2) Let any new person who opens "*" for input "gain control" of the
     input stream, and give it back to the guy who previously controlled
     it when the new one closes the file. This is like a "stack" where
     only the "top item" can read from the file.

If your handler gets "*" as filename and take appropriate actions
to meet the needs discussed above, you can use it as pr_ConsoleTask!

If on the other hand your handler doesn't recognizes "*" as a special case
it is not certain (and highly unlikely) that it will work.

File-systems doesn't work since two persons cannot write to "*" at
the same time.

NULL: works, since it is a null-device, and anybody who writes to it
succeeds and anybody who reads from it gets EOF. The above needs for
a "*" handler is fulfilled (but in a strange way I must admit).

CON: works since it treats "*" as a special case, and doesn't open
a new window. (A CON: handler can only handle one window anyway)

AUX: should work (but a haven't tested it)

NIL: does NOT work since it is a kludge. (it has no device process)

>	I have been testing NULL: at with my cron (setting pr_ConsoleDevice
>to DeviceProc("NULL:"), fclose(stderr), and EndCLI'ing the console window
>that started it and everything works fine!

Great. I hope they will make it work with NIL: in 1.4.
All those handlers are *so* tiresome to install :-)

  -- Gunnar

SNAIL: Gunnar Nordmark          VOICE: (+46) 8 - 755 42 52
       Nora strand 5
       S-182 34 DANDERYD        EMAIL: gno@stacken.kth.se
       SWEDEN                          gno@SESTAK.BITNET

"Words, words, words."  William Shakespeare