-=| Alexander Peshkoff, Fri, Apr 16, 2010 at 06:41:03PM +0400 |=-
> On Friday 16 April 2010 15:50:27 Damyan Ivanov wrote:
> > Hi,
> > Before Firebird 2.5, I was able to run the following:
> > gbak -b -v srv:db stdout | gbak -v -replace stdin localhost:db
> > For humans, this backs up a remote database and simultaneously
> > restores it on the local machine, with the output of the two processes
> > going to the terminal and without using an intermediate file to store
> > the backup.
> > With 2.5, gbak's output goes to stdout. Naturaly, this breaks the
> > restore process, as it sees invalid data.
> > I have prepared the attached patch (against 2.5-RC2) that makes gbak
> > output go to stderr as it was with 2.1.
> Are you absolutely sure that patch is attached? :-)
Hmpf. Here it is.
> Anyway - the problem is a bit more intetresting, cause it not only
> with gbak, but with a number of other utilities. I agree that output
> about errors must go to stderr, not stdout. And going to fix this.
> But what about output of -v switch, I'm not sure. Look at one more
> possible usage pattern:
> gbak -b -v srv:db db.gbak >db.lst
> I.e. one gets listing of copied objects in the file, but error
> messages should better stay on display.
As Dmitry wrote, I think -y switch fits here well.
> What about your sample - what's wrong with
> gbak -b srv:db stdout | gbak -v -replace stdin localhost:db
> With -v at both sides of pipe messages can mix on tty in random manner,
> suppose it does not make output look well.
It is not that bad. It helps verifying that both processes work. One
says "writing" and the other "restored".
Also, this wouldn't work if I want a compressed backup as in:
gbak -v srv:db stdout | gzip > db.fbk.gz
In this case -v is more useful than in my weird example.
> PS. What about 2 useless calls - I will kill them in 3.0, in 2.5 we
> do not do something except bugfixing.
OK. Although burning CPU cycles for no reason can be considered a bug