Yea, double check my original reply :) that's exactly what I thought you meant.
Niklas kind of threw the discussion off into a tangent which is probably why you're confused ;) These are two separate, but slightly related, issues: * David: Detection of arbitrary prompting in executed commands and "passing through" those prompts to the person running Fabric: not implemented, but on the list. * Niklas: Update of Fabric's own prompting mechanisms (i.e. asking the user for variables and such) to allow for password-like hidden user input: sort-of implemented, also on the list. -Jeff On Tue, Dec 16, 2008 at 1:56 PM, Hancock, David (dhancock) <[email protected]> wrote: > Just a quick check to be sure my "desirement" is captured: I'd like to be > able to run arbitrary shell scripts, usually not written by me, either via > 'run' or 'shell' and have their shell-ish prompts displayed and the end-user > entries captured and processed. Shell scripts can do some weird stuff to > turn off echoing of password entries, which is OK, but most of the prompts > and reads are visible. I'm not envisioning rewriting those third-party > scripts at all. > > That said, I have NO CLUE how to go about that, so it remains just a desire > that Fabric support arbitrary prompting from other programs. It seems > important for a deployment tool to be able to use the scripts that install > things we're deploying. > > Thanks for all that Fabric does already, and > Cheers! > -- > David Hancock | [email protected] > > This e-mail (including any attachments) is intended only for the use of the > individual or entity named above and may contain privileged, proprietary, or > confidential information. The information may also contain technical data > subject to export control laws. > > > ________________________________ > From: Niklas Lindström <[email protected]> > Date: Tue, 16 Dec 2008 17:32:56 +0100 > To: Jeff Forcier <[email protected]> > Cc: David Hancock <[email protected]>, <[email protected]> > Subject: Re: [Fab-user] I can't respond to prompts using Fabric "shell" or > "run" verbs > > On Tue, Dec 16, 2008 at 4:55 PM, Jeff Forcier <[email protected]> wrote: >> I think having a password-safe version of prompt() (either a separate >> command or an argument to prompt() itself) would be a good idea and I >> can't think of any obvious reason why it wouldn't work. The internal >> password related prompts use getpass (at least, they did when I last >> looked) and they work fine. > > I agree; I went with "naked" `getpass` and immediately wanted stuff > like "re-type" etc. I think it'd be cleaner to have a separate > operator for it (`password_prompt` is probably better than > `secret_password` unless someone can think of actual usecases for a > generic "secret value type"). > > I do think adding a "password expansion" like "$(passwd:password)" or > similar would be motivated by this, although it is an invasive change > for the benifit of one sole operator.. And how it should work.. > Explicit `del` (as in my example), or perhaps dropping the value once > used? I'm not sure.. > > >> I'll star this convo in my GMail and will make sure this gets added to >> the TODO list sometime =) > > I do that too. ;) I really recommend the "superstars" Lab feature for > that.. (What to recommend for actually taking time to implement my > ideas is another task.. Perhaps Philip J Eby's "Owners' Circle".. ;) ) > > > Best regards, > Niklas > > >> -Jeff >> >> On Tue, Dec 16, 2008 at 10:48 AM, Niklas Lindström <[email protected]> >> wrote: >>> Hm. Of course, I can just *use* getpass here, although I loose some of >>> the `prompt` features. Remaining then is whether some secret expansion >>> is still desirable (the solution of which may or may not make the >>> usecase of `secret_prompt` interesting again).. >> > _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
