[gentoo-user] Problem with script calling OOCalc on amd64

[gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1625 bytes --]

Hi All,

I have run into a problem which I cannot explain.  I am trying to run this 
script in a amd64 installation:

xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg && oocalc \ 
Personal/data.ods; shred --remove -z -v DATA/data.ods'

On a x86 system, oocalc launches, I use the file and when I close it shred 
removes it.  On the amd64 system, the file is shredded as soon as it is 
opened.  This is what happens:

[snip ...]
gpg: AES256 encrypted data
gpg: original file name='data.ods'
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 64/32768 bytes in 1 blocks
I18N: Operating system doesn't support locale "en_US"
shred: Personal/data.ods: pass 1/4 (random)...
shred: Personal/data.ods: pass 2/4 (random)...
shred: Personal/data.ods: pass 3/4 (random)...
shred: Personal/data.ods: pass 4/4 (000000)...
shred: Personal/data.ods: removing
shred: Personal/data.ods: renamed to Personal/00000000
shred: Personal/00000000: renamed to Personal/0000000
shred: Personal/0000000: renamed to Personal/000000
shred: Personal/000000: renamed to Personal/00000
shred: Personal/00000: renamed to Personal/0000
shred: Personal/0000: renamed to Personal/000
shred: Personal/000: renamed to Personal/00
shred: Personal/00: renamed to Personal/0
shred: Personal/data.ods: removed

Is this something 64bit specific?  Shouldn't xrterm behave the same in both 
x86 and amd64 with regards to this script?  How do I get it to keep oocalc 
open and shred to kick in only after the oocalc application is closed?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Amit Dor-Shifer]

What does

xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg;echo $?' tell you? I'm thinking that gpg fails, so oocalc never launches (because you conditioned its execution with '&&', and the script continues to shred the file.

My amd64 succeeds executing this (s/gpg/echo-to-tmpfile/). I would initially assume it's the usage causing the issue, rather than some arch-dependent thing.

Amit


Mick wrote:
> Hi All,
>
> I have run into a problem which I cannot explain.  I am trying to run this 
> script in a amd64 installation:
>
> xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg && oocalc \ 
> Personal/data.ods; shred --remove -z -v DATA/data.ods'
>
> On a x86 system, oocalc launches, I use the file and when I close it shred 
> removes it.  On the amd64 system, the file is shredded as soon as it is 
> opened.  This is what happens:
>
> [snip ...]
> gpg: AES256 encrypted data
> gpg: original file name='data.ods'
> random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
>               outmix=0 getlvl1=0/0 getlvl2=0/0
> secmem usage: 64/32768 bytes in 1 blocks
> I18N: Operating system doesn't support locale "en_US"
> shred: Personal/data.ods: pass 1/4 (random)...
> shred: Personal/data.ods: pass 2/4 (random)...
> shred: Personal/data.ods: pass 3/4 (random)...
> shred: Personal/data.ods: pass 4/4 (000000)...
> shred: Personal/data.ods: removing
> shred: Personal/data.ods: renamed to Personal/00000000
> shred: Personal/00000000: renamed to Personal/0000000
> shred: Personal/0000000: renamed to Personal/000000
> shred: Personal/000000: renamed to Personal/00000
> shred: Personal/00000: renamed to Personal/0000
> shred: Personal/0000: renamed to Personal/000
> shred: Personal/000: renamed to Personal/00
> shred: Personal/00: renamed to Personal/0
> shred: Personal/data.ods: removed
>
> Is this something 64bit specific?  Shouldn't xrterm behave the same in both 
> x86 and amd64 with regards to this script?  How do I get it to keep oocalc 
> open and shred to kick in only after the oocalc application is closed?
>   

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1091 bytes --]

On Tuesday 16 March 2010 07:40:04 Amit Dor-Shifer wrote:
> What does
> 
> xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg;echo $?' tell you?

It doesn't return anything on the terminal I launch it from, but decrypts the 
file in an xterm and then closes it (the xterm).  So the gpg part works fine.

>  I'm thinking that gpg fails, so oocalc never launches (because you
>  conditioned its execution with '&&', and the script continues to shred the
>  file.

The gpg part does not fail, because when I run:

xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg && oocalc \
Personal/data.ods'

An xterm opens up asks for a passwd to decrypt the file, decrypts it and 
launches OOo.  However, the xterm dies immediately after that.

On my x86 machine, the xterm stays open until I close OOo.  This is how it 
should work; i.e. the xterm should continue to run as long as any processes 
within it are still running.

This makes me think that it may be some env or profile difference ...?  What 
would control this behaviour in an xterm?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Amit Dor-Shifer]

ok. I didn't realize that oocalc actually executed in your first attempt.
Out of ideas then.

FWIW - a few guesses: I'd execute oocalc under strace, and try to find 
what is killing oocalc (does it decide to exit, or is it sent some 
signal). If your suspecting xterm to be the culprit (i.e., yr script 
works-as-expected w/o the xterm wrap) then maybe it'll be worthwhile 
looking into the X resources yr xterm is reading.
HTH
Amit

Mick wrote:
> On Tuesday 16 March 2010 07:40:04 Amit Dor-Shifer wrote:
>   
>> What does
>>
>> xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg;echo $?' tell you?
>>     
>
> It doesn't return anything on the terminal I launch it from, but decrypts the 
> file in an xterm and then closes it (the xterm).  So the gpg part works fine.
>
>   
>>  I'm thinking that gpg fails, so oocalc never launches (because you
>>  conditioned its execution with '&&', and the script continues to shred the
>>  file.
>>     
>
> The gpg part does not fail, because when I run:
>
> xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg && oocalc \
> Personal/data.ods'
>
> An xterm opens up asks for a passwd to decrypt the file, decrypts it and 
> launches OOo.  However, the xterm dies immediately after that.
>
> On my x86 machine, the xterm stays open until I close OOo.  This is how it 
> should work; i.e. the xterm should continue to run as long as any processes 
> within it are still running.
>
> This makes me think that it may be some env or profile difference ...?  What 
> would control this behaviour in an xterm?
>   

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 869 bytes --]

On Wednesday 17 March 2010 09:15:17 Amit Dor-Shifer wrote:
> ok. I didn't realize that oocalc actually executed in your first attempt.
> Out of ideas then.
> 
> FWIW - a few guesses: I'd execute oocalc under strace, and try to find
> what is killing oocalc (does it decide to exit, or is it sent some
> signal). If your suspecting xterm to be the culprit (i.e., yr script
> works-as-expected w/o the xterm wrap) then maybe it'll be worthwhile
> looking into the X resources yr xterm is reading.

That's interesting ... which Xresources is xterm reading?  I have this in my 
~/.Xresources:

aterm*loginShell:true
aterm*saveLines:32767
aterm*transparent:true
aterm*transpscrollbar:true
aterm*shading:40
aterm*fading:55
aterm*font:-*-fixed-*-*-*-*-20-*-100-*-*-*-*-*

but xterm (judging by the size of the font) does not use it.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2801 bytes --]

On Wednesday 17 March 2010 22:57:41 you wrote:
> On Wednesday 17 March 2010 09:15:17 Amit Dor-Shifer wrote:
> > ok. I didn't realize that oocalc actually executed in your first attempt.
> > Out of ideas then.
> >
> > FWIW - a few guesses: I'd execute oocalc under strace, and try to find
> > what is killing oocalc (does it decide to exit, or is it sent some
> > signal). If your suspecting xterm to be the culprit (i.e., yr script
> > works-as-expected w/o the xterm wrap) then maybe it'll be worthwhile
> > looking into the X resources yr xterm is reading.

I'm posting this to the list on behalf of Jack, because his posts don't make 
it to the list for some reason:

============================================
You didn't see it in the list because it hasn't shown up there yet,  
despite three tries to post.....

What I mean is that if I type "oocalc somefile" in a term (it doesn't  
seem to matter xterm, konsole, ...) I almost immediately get the next  
shell prompt, even before the oocalc (or oodraw or oowrite) window is  
fully displayed and ready to work.  It does not smell to me like  
anything to do with the terminal program, or even the shell, although  
there may well be an environment variable that OO is checking.   
oowriter --help (and any variation I have tried) seems to ignore the  
request for help.  If you look at the ooffice help on command line  
parameters, there is a note about gentoo having a custom version - but  
I haven't been able to find anything at the gentoo site either.  I have  
not yet tried launching from a script in case that behaves any  
differently.

Note that since the shell has given the next prompt - the terminal will  
certainly think everything is done, and happily close if the script is  
finished.  The trick will be to explicitly find a way to check that oo  
has finished.

If you just launch oo from a command line in a terminal, do you get the  
next shell prompt immediately, or not until you exit oo?

Jack
============================================

Thanks Jack, this is rather interesting:

On two machines including the amd64 laptop the terminal exits immediately, 
while the OOo is being launched.  Both of these have OOo compiled from 
source.  The third machine (an old x86 laptop) has the OOo binary installed.  
The binary installation behaves as I thought was the norm, i.e. the terminal 
does not exit, but remains open until I close OOo.  So this problem that 
reported I guess is due to a difference between the two types of OOo, built 
from source or binary.

I looked at the CLI help options by running 'ooffice -help'but I can't see 
anything in there that will change this behaviour on the OOo built from 
sources.

Any other ideas?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Robert Bridge]

On Wed, Mar 17, 2010 at 10:57 PM, Mick <michaelkintzios@gmail.com> wrote:
> That's interesting ... which Xresources is xterm reading?  I have this in my
> ~/.Xresources:
>
> aterm*loginShell:true
> aterm*saveLines:32767
> aterm*transparent:true
> aterm*transpscrollbar:true
> aterm*shading:40
> aterm*fading:55
> aterm*font:-*-fixed-*-*-*-*-20-*-100-*-*-*-*-*
>
> but xterm (judging by the size of the font) does not use it.

xterm isn't aterm is it? So it really shouldn't use the settings for a
different program.

Just a random thought.
RobbieAB

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 857 bytes --]

On Tuesday 23 March 2010 22:30:16 Robert Bridge wrote:
> On Wed, Mar 17, 2010 at 10:57 PM, Mick <michaelkintzios@gmail.com> wrote:
> > That's interesting ... which Xresources is xterm reading?  I have this in
> > my ~/.Xresources:
> >
> > aterm*loginShell:true
> > aterm*saveLines:32767
> > aterm*transparent:true
> > aterm*transpscrollbar:true
> > aterm*shading:40
> > aterm*fading:55
> > aterm*font:-*-fixed-*-*-*-*-20-*-100-*-*-*-*-*
> >
> > but xterm (judging by the size of the font) does not use it.
> 
> xterm isn't aterm is it? So it really shouldn't use the settings for a
> different program.
> 
> Just a random thought.

Yes, that's right.  xterm would read something like:

xterm*font:-*-blah-blah-

but I don't have anything in there, so was wondering where does it read its 
default size from?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Dan Wallis]

On 16 March 2010 12:41, Mick <michaelkintzios@gmail.com> wrote:
> Hi All,
>
> I have run into a problem which I cannot explain.  I am trying to run this
> script in a amd64 installation:
>
> xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg && oocalc \
> Personal/data.ods; shred --remove -z -v DATA/data.ods'
>
> On a x86 system, oocalc launches, I use the file and when I close it shred
> removes it.  On the amd64 system, the file is shredded as soon as it is
> opened.  This is what happens:

I get something similar with firefox: if it's the first instance, it
will block until I terminate firefox; but if there's already a firefox
running, it'll send a "open this URL" command to the other instance,
and close this new one.

I'm not sure if OOo is the same, but I'd recommend giving it a try.

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 907 bytes --]

On Thursday 18 March 2010 03:29:00 Dan Wallis wrote:
> On 16 March 2010 12:41, Mick <michaelkintzios@gmail.com> wrote:

> > On a x86 system, oocalc launches, I use the file and when I close it
> > shred removes it.  On the amd64 system, the file is shredded as soon as
> > it is opened.  This is what happens:
> 
> I get something similar with firefox: if it's the first instance, it
> will block until I terminate firefox; but if there's already a firefox
> running, it'll send a "open this URL" command to the other instance,
> and close this new one.
> 
> I'm not sure if OOo is the same, but I'd recommend giving it a try.

Hi Dan, my problem is not exactly the same.  It occurs on the first instance 
that I launch OOo from the terminal.

Is there some bash incantation I can use then with OOo compiled from source, 
to keep the terminal open until I close OOo?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Dan Wallis]

On 19 March 2010 08:42, Mick <michaelkintzios@gmail.com> wrote:
> Is there some bash incantation I can use then with OOo compiled from source,
> to keep the terminal open until I close OOo?

I guess something like this might do the trick:
    while pgrep ooffice >/dev/null; do sleep 1; done
Although I'm not at my Gentoo box at the moment to test. The version
of pgrep on this Debian box doesn't have a -q option, hence the
redirect to devnull.

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 839 bytes --]

On Friday 19 March 2010 00:34:44 Dan Wallis wrote:
> On 19 March 2010 08:42, Mick <michaelkintzios@gmail.com> wrote:
> > Is there some bash incantation I can use then with OOo compiled from
> > source, to keep the terminal open until I close OOo?
> 
> I guess something like this might do the trick:
>     while pgrep ooffice >/dev/null; do sleep 1; done
> Although I'm not at my Gentoo box at the moment to test. The version
> of pgrep on this Debian box doesn't have a -q option, hence the
> redirect to devnull.

Thanks Dan, I tried this but the terminal did not wait for OOo to close.  It 
exited straight away:

xterm -fg green -bg black -e 'gpg DATA/data.ods.gpg && oocalc DATA/data.ods; 
while pgrep oocalc >/dev/null; do sleep 1; done'

I also tried /usr/bin/oocalc, but it didn't work.  :-(
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Steve Dommett]

On Friday 19 March 2010 19:14:21 Mick wrote:
> I also tried /usr/bin/oocalc, but it didn't work.  :-(
Try:
oocalc -no-oosplash

:-)

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 517 bytes --]

On Tuesday 23 March 2010 10:18:59 Steve Dommett wrote:
> On Friday 19 March 2010 19:14:21 Mick wrote:
> > I also tried /usr/bin/oocalc, but it didn't work.  :-(
> 
> Try:
> oocalc -no-oosplash
> 
> :-)

Yes!  That fixed it.  :-)  Thank you very much.

I saw this option but never thought that it would make any difference on the 
terminal behaviour.  Do you know why it behaves differently with -no-
oosplash, when the binary installation does not seem to be bothered either 
way?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with script calling OOCalc on amd64

[Steve Dommett]

On Tuesday 23 March 2010 16:04:04 Mick wrote:
> Do you know why it behaves differently with -no-
> oosplash, when the binary installation does not seem to be bothered either
> way?

It seems the binary package doesn't install the optional oosplash.bin program.

The code responsible for the differing results lies in the last 25 lines of 
/usr/lib64/openoffice/program/soffice.

Cheers,
  Steve