Re: \prompt for psql

On 2/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Chad Wagner" <chad(dot)wagner(at)gmail(dot)com> writes:
> > Would it make sense to say:
> > 1. if pset.notty is set and '-f' switch is not set then use
> simple_prompt
> > 2. else then use gets_fromFile(stdin) <or some other alternative?>
>
> Actually, there's another issue, which is where to send the prompt.
> If we're using /dev/tty the answer is clear, but if we're proposing to
> read from stdin then it's not necessarily the case that stdout (or even
> stderr) is appropriate.
>
> Arguably a prompt is useless except to a human user, so maybe the rule
> is "if stdin is a tty according to pset.notty, then prompt to /dev/tty;
> otherwise suppress the prompt altogether". Or we could prompt to stderr
> instead of /dev/tty in this case. I'm not sure if there are plausible
> use-cases where stdin leads to the terminal and stderr doesn't.
>

pset.notty will be set to 1 if either stdin or stdout is not a tty. So in
the case where they are redirecting both input and output then it will
prompt on /dev/tty, otherwise the prompt would go out on stdout.

I was thinking perhaps it should look at the '-q' quiet switch for
determining whether to display prompt at all. So perhaps with a '-q' switch
instead of dumping the prompt to stdout it should always be sent to
/dev/tty. Also, I think in general most users of this feature that would be
"scripting" output (via expect or similar) would probably just use the '-v'
switches.

BTW, attached is the latest version of this patch that includes the code
(and updates to the psql-ref.sgml) I talked about earlier. Not sure if
gets_fromFile is favored, or perhaps the creation of a psql_prompt_var
routine that takes into account some of what simple_prompt is doing but
considering the logic we are discussing.