On Tue, Nov 06, 2001 at 07:58:41PM -0500, Glenn Maynard wrote: > > BTW, other tty output in lftp is blocking also. I remember that > > making tty non-blocking can cause funny side effects in other programs. > > So, e.g. `cat' command can also block other transfers. > > Well, the difference is that most operations aren't around for a long > time; typically a cat runs and then finishes (unless it's something > silly like catting a pipe.) The status line stays there for long > periods of time.
The problem with cat would happen if the terminal stops, e.g. by ^S. > > Is global buffering is really needed? Maybe it is better to have a separate > > buffer in each job, like it is done now. > > Well, it could put buffer handling in one place (instead of each job > doing different things with fds), it'd allow things like safe status > line buffering; we could even keep jobs running when we fork a shell, > buffering data until it exits. > > As far as other programs, the tty should be blocking when it's given > to a subshell. If we run "!vi foo", we can run a scheduling loop in the > parent. If the subshell's backgrounded, it'll walk over the buffering, > but that happens anyway. > > However, it'd be a major project: standardize output, have stdout, > stderr and maybe a separate status line output stream before commands > are run. It'd be useful in the sense of "the download must go on", but > it's definitely not urgent. I think terminal abstraction layer (is it correct term?) is needed. Then a TtyBuffer can be defined. > > I already treat ENFILE and EMFILE as non-fatal. Maybe ENOSPC should be > > treated similarly. > > Yeah--optionally (defaulting on, to enforce lftp's "no errors are fatal" > claim.) Some people wouldn't want this. Some errors are fatal. E.g. EPERM, ENOENT and many others. Even ftp protocol errors 5xx are treated as fatal, with some exceptions. > Some way of setting some errors as needing a new control connection > would be useful. I've hit servers with bogus quotas in place: you can > download so much, then you just keep getting out-of-quota errors until > you reconnect. It's done to give other people a chance to get in, > presumably--you disconnect and get to redial the server again. (They > typically have connection queueing.) Unfortunately, lftp doesn't know > it's supposed to do that, and chews through the queue. I'm not sure > of a clean way to do this; perhaps a regex matching all error codes? > Currently, I work around this by queueing "close" periodically. There is ftp:web-mode, which closes connection after each data transfer. Maybe it is overkill for this case, but it should work. -- Alexander. | http://www.yars.free.net/~lav/
