Firebird

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? :-)

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. 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.

Alex.

PS. What about 2 useless calls - I will kill them in 3.0, in 2.5 we do not do 
something except bugfixing.

16.04.2010 16:41, Alexander Peshkoff wrote:
> 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.

   Isn't -Y supposed to be used for that?

-- 
   SY, SD.

On Friday 16 April 2010 18:48:41 Dimitry Sibiryakov wrote:
> 16.04.2010 16:41, Alexander Peshkoff wrote:
> > 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.
>
>    Isn't -Y supposed to be used for that?

-Y redirects error messages too. At least in 2.1.

-=| 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 
:)

On Friday 16 April 2010 19:03:48 Damyan Ivanov wrote:
> As Dmitry wrote, I think -y switch fits here well.

did you try how does it work?

> 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.

yes, agreed
worth changing

> > 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

They present since IB times. Not for RC3 stage IMHO - or we will never have a 
release :-)

What about the rest of your patch - sorry, it's wrong. It breaks redirect 
of -v output when gbak is used as service. Don't worry - I agree the problem 
is present and will take care about it.

Alex.

-=| Alexander Peshkoff, Fri, Apr 16, 2010 at 07:15:16PM +0400 |=-
> On Friday 16 April 2010 19:03:48 Damyan Ivanov wrote:
> > As Dmitry wrote, I think -y switch fits here well.
> 
> did you try how does it work?

I did to some extent:

    $ gbak -b -v -y /dev/stderr srv:db stdout > /dev/null
    gbak:cannot open status and error output file /dev/stderr
    $ ls -l /dev/stderr
    lrwxrwxrwx 1 root root 15 15 апр 12,24 /dev/stderr -> /proc/self/fd/2

Yes, I could probaby workaround this by directing -y to a file and 
running 'tail -f' in another terminal, but this is not the point.

> > > 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
> 
> They present since IB times.

Well, *sigh* :)

> Not for RC3 stage IMHO - or we will never have a release :-)

Understood.

> What about the rest of your patch - sorry, it's wrong. It breaks 
> redirect of -v output when gbak is used as service.

Ugh.

> Don't worry - I agree the problem is present and will take care 
> about it.

Thanks! I'll watch CVS and learn.

-=| Alexander Peshkoff, Fri, Apr 16, 2010 at 07:15:16PM +0400 |=-
> What about the rest of your patch - sorry, it's wrong. It breaks 
> redirect of -v output when gbak is used as service. Don't worry 
> - I agree the problem is present and will take care about it.

I wonder if there is progress on this. Can I help somehow?

Should I create a ticket about the issue?

On Friday 30 April 2010 19:11:10 Damyan Ivanov wrote:
> -=| Alexander Peshkoff, Fri, Apr 16, 2010 at 07:15:16PM +0400 |=-
>
> > What about the rest of your patch - sorry, it's wrong. It breaks
> > redirect of -v output when gbak is used as service. Don't worry
> > - I agree the problem is present and will take care about it.
>
> I wonder if there is progress on this. Can I help somehow?

Right now working on it. There are some related bugs, and I want to solve them 
all together.

> Should I create a ticket about the issue?

Yes, please do.

-=| Alexander Peshkoff, Fri, Apr 30, 2010 at 07:23:52PM +0400 |=-
> On Friday 30 April 2010 19:11:10 Damyan Ivanov wrote:
> > Should I create a ticket about the issue?
> 
> Yes, please do.

Done, http://tracker.firebirdsql.org/browse/CORE-2984

Thanks.