On Thu, Nov 29, 2001 at 01:58:56PM -0500, Glenn Maynard wrote: > > > It would be good to have ftp:disallow-chmod or some option in mirror > > > command... > > > > I'll add ftp:use-site-chmod setting. > > I wouldn't recommend that--not for this reason alone, anyway. Note that > this is exactly the same problem he was having with MKD--he's probably > receiving a 5xx code here, too. (And we probably shouldn't add > "ftp:use-mkd".)
If he really needs persist-retries on (I'd be interested in knowing why), there's mirror --no-perms, too. (The rest of this message is fairly long and only related peripherally to this thread; it ended up quite tangental. The latter half is "far off wishlist" type stuff. Alex, if you're busy, no problem if you delay reading it. I'd be interested in hearing your opinion on the GUI-ish related stuff, but none of it is possible without full output buffering.) Global settings for all optional or oft-broken site capabilities might be useful, to remember unsupported things after the first rejection--particularly helpful with FEAT, but very few servers support that. That would be for 50x replies, however, not 55x (for the general "unsupported command/SITE" case, at least.) It'd make a good place to remember when MDTM isn't supported; I've had mirror commands spam the output with 500's for that. Was this fixed? I never remembered to report it. It'd be nice if the 500 for commands we know may not be supported be moved to a higher priority, too. The command doing the MDTM should produce a warning or error if appropriate for things we know are optional. If a mirror -R's SITE CHMOD fails, we should print a warning once; it's not fatal to the job. If a CMD(chmod)'s SITE CHMOD fails, we should print an error. (On the other hand, if something fails but we find a feature-equivalent fallback, we don't need to print anything at all. NLST after LIST when we don't need extra info, for example.) (Avoiding confusion: I'm using GUI to refer to any non-CLI interface, in this case terminal-menu type stuff. I'm not suggesting anything X at all.) A better way to manage active mirrors would be nice, but this is tricky. I can easily envision a GUI interface: do a full traversal in advance so the entire download is known at the beginning (cost), then during the job, display a tree with checkboxes to select and deselect individual trees. This is trickier with a CLI; and it's currently rather tricky to interact with active jobs--nothing ever does this, as far as I can tell. There are no provisions for interacting with the user from within a job, either. That would be needed for this, and might help elsewhere (ie. nonblocking GetPass.) Unfortunately, it's no small project. It has similar problems as running an ncurses app with a background job running (mangling the cursor pos, printing output in inappropriate places, etc.) That can't easily be fixed without something like the output buffers we discussed earlier. (And even with that, it'd take some design to figure out where to put stuff; split screens, like some apps use, are very unintuitive.) Possibly, rather than trying to give jobs some kind of access to the terminal (which could get messy), "draw screen to buffer" and "receive keypress" virtuals could be used. I expect a couple people to shout "but lftp is CLI; adding terminal-menu type stuff is ***." (Which would be a fair response, of course.) I'll point out that CLI is good for some things, and GUIs are good for other things. Sometimes the difference is extreme. Anyone on this list knows what CLIs can do that GUIs can't; and there are some things that GUIs are much better at than CLIs. Want to move all files between two dates from one directory to another? You can do it, if you muck with find and xargs for a while; but in Windows file explorer, you simply sort the display by date, select, and move. That said, we should be very careful before doing anything GUIish, of course--anything with that type of interface *can't be scripted*--but we shouldn't "CLI to the death" and end up with something like most of the Napster clients for Linux were. (Napster with a traditional ircii-like interface--it just didn't work.) However, if the GUI way has major advantages, but the CLI way has others, it doesn't hurt to have both. For example, a GUI interface for selecting files has two obvious advantages. First, it's easy to select a lot of distinct files quickly. (If I want to select 20 files that don't fit an expression--"all files about books I've read", GUI is quicker, especially when tab completion is inconvenient.) Second, conversion is possible. (If I have an ISO-8859-1 terminal, and the server is known to be UTF-8, a GUI can convert filenames for display; a CLI can't do that.) Anyway, something to think about. It has a lot of needed support work to make it "far horizon" at best. -- Glenn Maynard
