Re: [gentoo-user] Problem with script calling OOCalc on amd64
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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
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
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On Wed, Mar 17, 2010 at 10:57 PM, Mick michaelkintz...@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
On Tuesday 23 March 2010 22:30:16 Robert Bridge wrote: On Wed, Mar 17, 2010 at 10:57 PM, Mick michaelkintz...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On Friday 19 March 2010 00:34:44 Dan Wallis wrote: On 19 March 2010 08:42, Mick michaelkintz...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On Thursday 18 March 2010 03:29:00 Dan Wallis wrote: On 16 March 2010 12:41, Mick michaelkintz...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On 19 March 2010 08:42, Mick michaelkintz...@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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On 16 March 2010 12:41, Mick michaelkintz...@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
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 (00)... shred: Personal/data.ods: removing shred: Personal/data.ods: renamed to Personal/ shred: Personal/: renamed to Personal/000 shred: Personal/000: renamed to Personal/00 shred: Personal/00: renamed to Personal/0 shred: Personal/0: renamed to Personal/ shred: Personal/: 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?
[gentoo-user] Problem with script calling OOCalc on amd64
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 (00)... shred: Personal/data.ods: removing shred: Personal/data.ods: renamed to Personal/ shred: Personal/: renamed to Personal/000 shred: Personal/000: renamed to Personal/00 shred: Personal/00: renamed to Personal/0 shred: Personal/0: renamed to Personal/ shred: Personal/: 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 signature.asc Description: This is a digitally signed message part.
