[9fans] fscons bug

[9fans] fscons bug

[dvd]

cpu% con -l /srv/fscons << EOF
fsys main
df
EOF
cpu% con -l /srv/fscons
main: 396,304,384 used + 105,299,968 free = 501 604 352 (79% used)

That is, after the recent changes, the output is not flushed after a command,
so it is not printed until fscons is opened the next time.

David

Re: [9fans] fscons bug

[rog]

> cpu% con -l /srv/fscons << EOF

how is con supposed to know that it should wait for some output
from the transaction?

Re: [9fans] fscons bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

i wondered whether expect(1) could be useful.
just a thought: don't blame me if it isn't!

[-- Attachment #2: Type: message/rfc822, Size: 2213 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fscons bug
Date: Thu, 24 Jun 2004 18:53:05 +0100
Message-ID: <7453868c152cc2e88a2c895aaafff3fc@vitanuova.com>

> cpu% con -l /srv/fscons << EOF

how is con supposed to know that it should wait for some output
from the transaction?

Re: [9fans] fscons bug

[rog]

expect is huge. (it includes all of tcl).

it seems to me that there's room for a filesystem control interface
to fossil (in fact the interactive element could just be an interface
to that) and then hacks such as expect would be unnecessary
for this purpose, and more sophisticated programmability
would be straightforward.

same applies to venti. what's with that http interface anyway?

Re: [9fans] fscons bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 39 bytes --]

humph.  see man 1 expect
dial/expect

[-- Attachment #2: Type: message/rfc822, Size: 2484 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fscons bug
Date: Thu, 24 Jun 2004 19:17:16 +0100
Message-ID: <9f994caae0ea0e0ae90967a06ac6ce7b@vitanuova.com>

expect is huge. (it includes all of tcl).

it seems to me that there's room for a filesystem control interface
to fossil (in fact the interactive element could just be an interface
to that) and then hacks such as expect would be unnecessary
for this purpose, and more sophisticated programmability
would be straightforward.

same applies to venti. what's with that http interface anyway?

Re: [9fans] fscons bug

[rog]

> humph.  see man 1 expect

sorry, that'll teach me to type "whatis expect" and assume
the worst...

Re: [9fans] fscons bug

[Scott Schwartz]

| expect is huge. (it includes all of tcl).
| 
| it seems to me that there's room for a filesystem control interface
| to fossil (in fact the interactive element could just be an interface
| to that) 

Yeah, like the original, tiny, tcl!

Re: [9fans] fscons bug

[dvd]

>> cpu% con -l /srv/fscons << EOF
> 
> how is con supposed to know that it should wait for some output
> from the transaction?

OK. I don't understand something basic.

cpu% con -l /srv/fscons
fsys main
df
 .... waiting a few minutes...
df 
.... waiting a few minutes and still nothing happens
df 
... gave up ... Ctl-\ Ctl-D
cpu% con -l /srv/fscons
main: 396,304,384 used + 105,299,968 free = 501 604 352 (79% used)
main: 396,304,384 used + 105,299,968 free = 501 604 352 (79% used)
main: 396,304,384 used + 105,299,968 free = 501 604 352 (79% used)

Re: [9fans] fscons bug

[rog]

> cpu% con -l /srv/fscons
> fsys main
> df
>  .... waiting a few minutes...

if it's still happening when being used interactively, that does
indeed sound like a bug. it was just the <<EOF business
that looked suspicious to me.

Re: [9fans] fscons bug

[boyd, rounin]

> >> cpu% con -l /srv/fscons << EOF
> > 
> > how is con supposed to know that it should wait for some output
> > from the transaction?
> 
> OK. I don't understand something basic.

yeah, con exits when reading fd 0 returns EOF, which will be
pretty ricky-tick on a here document.

RTFS