On Thu Aug 13 06:04:18 2015, TIMB wrote:
Show quoted text> For example, in a repo where "git rebase -i"would open an editor, try
> this:
>
> perl -MGit::Repository -we 'Git::Repository->new->run("rebase","-i")'
>
> It hangs. Running pstree I see:
>
> perl,13354 -MGit::Repository -we Git::Repository->new->run("rebase","-
> i")
> └─git,13366 rebase -i
> └─git-rebase,13367 /usr/libexec/git-core/git-rebase -i
> └─vim,13440
> /home/tim/trunk/comp/support_stripes/.git/rebase-merge/git-rebase-todo
And what would be the expected behaviour?
If the perl program is attached to a terminal (-t STDIN is true),
then effectively run the EDITOR and wait until it's done?
And if not attached to a terminal, just fail?
Would that work for you?
The fail case is easy: delete EDITOR from %ENV if -t STDIN is false.
$ perl -Ilib -MGit::Repository -e '$r=Git::Repository->new; delete $ENV{EDITOR}; $r->run( qw( rebase -i master ) )'
fatal: Terminal is dumb, but EDITOR unset
Could not execute editor at -e line 1.
If running in a terminal, then running system() would work.
(And be portable, I think. At least more than trying to
reattach the filehandles in the right place.)
If you want to run the "interactive" command in a non-interactive way,
i.e. have a program process the content of the file generated by git
before handing control back to git, one way would be to put the
whole command line in $ENV{EDITOR}. Sounds fragile and ugly, but
I wonder if there are other ways to keep git waiting for the EDITOR
to finish, while replacing the file by your own version (and avoiding
race conditions).
* * *
I wonder if adding an 'interactive' option to System::Command is not
the simplest and most generic way to handle this situation (at least
when trying to handle the first two cases): when interactive is true,
then die (in System::Command) if -t is false, and otherwise call system()
instead of the internal spawn command.
What do you think?