Re: [bug-gettext] gettextize requires confirmation from /dev/tty to complete

[Stefano Lattarini]

On Wednesday 14 December 2011, Bruno Haible wrote:
> Hi Stefano,
>
Hi Bruno.
 
> > Yes, the gettextize script from the gettext git repository forces the
> > caller to press enter *at the console* to complete its execution.  And
> > there's no way to avoid or work around this this (other than hacking
> > the gettextize script itself).
> > ...
> > how do you know whether a script
> > is "abusing" gettextize rather than simply using it in a non-common way
> > for a non-commmon but legitimate purpose?
> 
> I assume you have read the first two paragraphs of its documentation [1].
>
Oops, no, I just read its manpage; I hate using `info' from the command
line, and I didn't look at the online documentation.  My bad, sorry.

> It mentions that some tasks have to be done *manually* after running
> 'gettextize'.
> 
> What is the "non-common way for a non-commmon but legitimate purpose" that
> you are thinking of?
>
To fix this problem in the automake testsuite:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9807>

I need find and/or copy all the `.m4' files from libtool and gettext
(preferably without much efforts and room for failure), in a way
that makes it easy for the testsuite to access them.  The use of
`libtoolize --install' easily solves the problem for libtool >= 2.0,
and the use if `gettextize' would easily solve it for gettext, it it
weren't for the behaviour I've reported.

> > for which the only "reason" I can see is the one given in the comments:
> > 
> >   echo "Press Return to acknowledge the previous $count."
> >   # Read from /dev/tty, not stdin, so that gettextize cannot be abused
> >   # by non-interactive tools.
> >   read dummy < /dev/tty
> > 
> > which seems an absurd reason to me
> 
> Let me explain the reason in different words. Before it became clear that
> 'gettextize' and 'autopoint' need to be two different programs, people used
> 'gettextize' in their scripts. And then reported bugs because in some cases
> gettextize did the complete job and in other cases it didn't.
> 
> Then I created the 'autopoint' program to deal with the fully automatable
> case.
>
Ah, ok.  Then all makes more sense, and I'd like to change my advice:

  1. the message print by gettextize should suggest the use of
     autopoint for non-interactive usage;

  2. gettextize might exit with failure if the user doesn't give
     interactive confirmation after, say, one or two minutes; a
     "spurious" failure is better then an hang IMHO, in case someone
     erronously uses gettextize in a non-interactive fashion (as I
     did);

  3. I still think that a flag to allow the user override this
     "interactive cofirmation required" check would be worthwhile:
     the user should always be allowed to shoot himself in the
     foot if he wants to.
     
> But people had their scripts already written. This statement here is
> a reminder to all those who use old scripts from the pre-autopoint era,
> to change their scripts to use 'autopoint'.
>
And this approach would continue even if my suggestion of a new switch
for gettextize to make it run non-interactively is accepted, right?

> > I find this to be a very unfriendly an un-unixy behaviour
> 
> Ah but then every GUI program that pops up a dialog is "very unfriendly"
> and "un-unixy".
>
Absolutely!  I can only accept dialogs and prompts for passwords and
crypto stuff; for the rest, they are evil, evil, evil :-)

Thanks,
  Stefano