cpu opens new empty acme buffer each time it runs

[GoogleCodeExporter]

[What steps will reproduce the problem?]
Run cpu(1) directly, or within a script run, from Acme with
a middle click.  An empty buffer opens with no filename.

[What is the expected output? What do you see instead?]
Cpu does not open an extraneous new Acme buffer.
Cpu opens an extraneous new Acme buffer.

[Which operating system are you using?]
Inferno hosted on Ubuntu Linux.

[Please provide any additional information below.]
If run within Acme, it appears this code opens a new, empty buffer.
I don’t think it’s the intent of the code to do so, so how do we fix it?

cpu.b:91:   # To make visible remotely
cpu.b:92:   if(!exists("/dev/draw/new"))
cpu.b:93:       sys->bind("#d", "/dev", Sys->MBEFORE);

I see a new, empty buffer open each time I run cpu from Acme,
either by highlighting and running cpu directly, or within a script.
I think the access of /dev/draw/new in cpu.b:92 is the reason,
since the command {ftest -e /dev/draw/new} has the same effect.
I’d like no buffer to open, since I’m writing a build tool that may
call cpu many times, and I’d like to run it from Acme without
cluttering the screen.

Original issue reported on code.google.com by jason.ca...@gmail.com on 27 May 2013 at 6:18

[GoogleCodeExporter]

workaround script, deletes all empty windows:

#!/dis/sh
cpu $*

apply {
    tag = $1
    dir = `{echo $tag | sed 's,/[^/]+$,,'}
    if {grep -s '^ Del' $tag} {echo del > $dir/ctl}
} /mnt/acme/[0-9]*/tag

Original comment by jason.ca...@gmail.com on 28 May 2013 at 9:06

[GoogleCodeExporter]

It's doubly silly because #d hasn't been the draw device for a decade.
I've removed that and tidied up a few other things.
Possibly it should change to implement the same protocol as Plan 9's cpu, but
that's a bigger change, and I'll leave it for later.

CHANGES
appl/cmd/cpu.b
dis/cpu.dis
include/version.h
committed changeset 553:0e15d67d051b

Original comment by Charles....@gmail.com on 29 May 2013 at 10:11

• Changed state: Fixed