fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] I can't respond to prompts using Fabric "shell" or "run"


From: Hancock, David (dhancock)
Subject: Re: [Fab-user] I can't respond to prompts using Fabric "shell" or "run" verbs
Date: Tue, 16 Dec 2008 13:56:29 -0500
User-agent: Microsoft-Entourage/12.15.0.081119

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 | address@hidden

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 <address@hidden>
Date: Tue, 16 Dec 2008 17:32:56 +0100
To: Jeff Forcier <address@hidden>
Cc: David Hancock <address@hidden>, <address@hidden>
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 <address@hidden> 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 <address@hidden> 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)..
>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]