9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] fmt(1) standard behaviour
       [not found] <<fe41879c0910181300s3e1ba6efueda064db0b8a474@mail.gmail.com>
@ 2009-10-18 21:33 ` erik quanstrom
  2009-10-18 22:25   ` Rudolf Sykora
  0 siblings, 1 reply; 4+ messages in thread
From: erik quanstrom @ 2009-10-18 21:33 UTC (permalink / raw)
  To: 9fans

> it never actually formats any lines. If, on the other hand, while
> formatting on stdin, fmt(1) formatted on a line-by-line basis (per
> '\n'), then its use (at least for me) could be greatly widened.

i don't think this will help.  unless you multithread fmt (seems silly),
you're going to have the input or output blocking problem.  you
can imagine an arbitrarly long line choking your proposed setup,
as you can imagine that outputting on '\n' to confuse you if you
expect output after every line.

- erik



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] fmt(1) standard behaviour
  2009-10-18 21:33 ` [9fans] fmt(1) standard behaviour erik quanstrom
@ 2009-10-18 22:25   ` Rudolf Sykora
  2009-10-19 11:43     ` roger peppe
  0 siblings, 1 reply; 4+ messages in thread
From: Rudolf Sykora @ 2009-10-18 22:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I may not fully understand the problem, but wouldn't it be just fine
if fmt output anything it can already output?
I.e., filled lines are output, on encountering '\n' the (generally
unfilled) line is output...
(Or what is the reason that fmt waits for EOF?)

R



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] fmt(1) standard behaviour
  2009-10-18 22:25   ` Rudolf Sykora
@ 2009-10-19 11:43     ` roger peppe
  0 siblings, 0 replies; 4+ messages in thread
From: roger peppe @ 2009-10-19 11:43 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

the reason is that the algorithm is
simpler if fmt reads all the words and then
formats them.

if you could modify the source in a simple way to make it
incremental (for instance by flushing the words at
the end of each paragraph) i imagine the patch
might be accepted.

2009/10/18 Rudolf Sykora <rudolf.sykora@gmail.com>:
> I may not fully understand the problem, but wouldn't it be just fine
> if fmt output anything it can already output?
> I.e., filled lines are output, on encountering '\n' the (generally
> unfilled) line is output...
> (Or what is the reason that fmt waits for EOF?)
>
> R



^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] fmt(1) standard behaviour
@ 2009-10-18 20:00 Akshat Kumar
  0 siblings, 0 replies; 4+ messages in thread
From: Akshat Kumar @ 2009-10-18 20:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

As it stands, if not specified a file, fmt(1) takes input from stdin.
In doing so, it waits for EOF before outputting the formatted
lines. I haven't looked into the code, but I suppose it was left
this way due to simplicity (from basic file handling). However,
I doubt fmt(1) is used interactively enough to further merit
waiting for EOF (^D) when taking input from stdin. But it is a
problem when trying to pipe a program that, i.e., operates on a
file that blocks reads, to fmt(1). Since fmt(1) waits for EOF,
it never actually formats any lines. If, on the other hand, while
formatting on stdin, fmt(1) formatted on a line-by-line basis (per
'\n'), then its use (at least for me) could be greatly widened.

I don't mind implementing this, but perhaps others have different
methods of achieving the same (short of implementing the
behaviour of fmt(1) in each application that operates on files which
block reads), or generally a better "fix" than that suggested above.
Thoughts?


Best,
ak



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-10-19 11:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <<fe41879c0910181300s3e1ba6efueda064db0b8a474@mail.gmail.com>
2009-10-18 21:33 ` [9fans] fmt(1) standard behaviour erik quanstrom
2009-10-18 22:25   ` Rudolf Sykora
2009-10-19 11:43     ` roger peppe
2009-10-18 20:00 Akshat Kumar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).