Apache OpenOffice (AOO) Bugzilla – Issue 69143
Can't Double-Click to Open Special Character Pathnames
Last modified: 2007-12-18 13:18:22 UTC
I tried to open an OOo text document by double-clicking it (I usually open it through OOo's open command in the file menu). OOo/X11 was not running at the time. The file resides on an external hard disk, pathname: /Volumes/Extra HD/Documents/Stuff/Mo' Stuff/Articles/foobar.odt Although OOo (and X11) started up fine I got an error message displayed by OpenOffice.org 2.0 in a dialog box: sh:-c: line 1: unexpected EOF while looking for matching `" sh:-c: line 2: syntax error: unexpected end of file The dialog gives the choice of two buttons "Edit" and "OK". If I click "OK", OOo quits and X11 is still running. If I click "Edit", Script Editor opens and displays an error dialog: Open Dictionary Unable to read the dictionary of the application or extension because it is not scriptable. ...with an "OK" button as the only option. After clicking "OK" then another error dialog pops up, still from Script Editor: The document"droplet.rsrc" could not be opened. Script Editor cannot open files in the "Document" format. Now I realize, I think, that the OpenOffice.org 2.0 file is some kind of Applescript thingy and those errors are Applescript related. But the real problem, I believe, is the apostrophe after "Mo" in that pathname. OOo can't deal with it. I get these errors when double-clicking on any OOo created file (or MS Office file) that is in that "Mo' Stuff" folder. I can double-click on any other OOo (or MS Office) file that's not in "Mo' Stuff" and OOo will run and open it. I can also open files from that folder through OOo's File->Open menu command. And I can create/save files in Mo' Stuff. I justs can double- click to open them. I usually find it easier to open files in that directory through the open command of OOo, but there are times when I have that folder open and I can't believe I've *never* opened an OOo file from there by double-clicking it; therefore I'm thinking I must've double-clicked an OOo file before and it worked and that this is a new error in 2.0.3. I've never filed an issue bnefore and may have done some things wrong. Thank you!
smsm1 -> yocraig: Very good for your first attempt. One change needed: component should be porting, and subcomponent should be Mac OS X
.
I've found a fix, that will need to be fully tested: Replace set theFilePath to "'" & (POSIX path of theDocument) & "'" with set theFilePath to (quoted form of POSIX path of theDocument) I'd like to thank Google and http://www.macdevcenter.com/pub/a/mac/2005/02/11/applescript.html? page=2 for the inspiration. Hope this helps.
smsm1 -> yocraig: Can you please check that this fix works? Control+click the OpenOffice.org 2.0.app bundle and choose "show package contents". A new window will appear. Enter the following folders: "Contents" > "Resources" > "Scripts". There you should see the file "main.scpt". Please make a modification to that file, and get back in touch to say if it works. Thanks
Sorry for the delay! I've moved to a new apartment and I was offline for a few days. Your fix works! Changing that one line in "main.scpt" was all it took. Apostrophes in the pathnames no longer causes errors...OOo just opens them right up. Thanks!!
smsm1 -> yocraig: Thanks for confirming this fix. Unfortunately it has come too late to appear in the next release 2.0.4. It will however appear in the release after that, 2.1 (formally 2.0.5). Please take a look at http://wiki.services.openoffice.org/wiki/ OOoRelease205 for the release schedule of 2.1. This minor but significant change can be applied to the next release, which is likely to be out in the next month.
Need to double check to make sure that all occurrences of this issue in both main.scpt and PostInstall.scpt are covered in any patch made.
Created attachment 39076 [details] Patch that fixes problems with paths having exotic characters
The patch above corrects the problem mentioned above and also fixes all the similar problems with the scripts. Also, the logging function logEvent() should now be save to use for any message string. obr: can you get this into some CWS for testing and integration?
Will do. Can't promise any specific date though.
Patch commited to CWS pj64 (CVS tag: cws_src680_pj64). @mox: please verify.
I'm giving it a go, but http://www.openoffice.org/issues/show_bug.cgi?id=70965 will probably cause it to fail.
Did not build the cws, but verified that the applescript files in the cws are identical to my local copies. Have already done earlier the testing with the local copies, so this should be ok to go. smsm1: if your latest build fails, it probably would be enough to remove the desktop -module of an earlier OOo build and copy the desktop -module from cws_src680_pj64 and then build & deliver first the desktop module and then instsetoo_native.
I can verify this fix works, Please read below. Just ran the oobuildbot setting it to build the CWS pj64, and I can now open all files that have the characters " and/or ' in their name. Please see http://ooo-staging.osuosl.org:8010/MacPort1/builds/51 , unfortunately due to a bug in the buildbot, it did not upload the install set created. If anyone would like a copy of this build please contact me directly. I have just taken a look at the file and there are many places in the 2 files, where "quoted form of" is not used beside a "POSIX path", is this the way it is meant to be? Things like the XServer shouldn't have a ' or " in their path/filename, but they could, and thus this patch could therefore fail for those who have renamed their XServer. (I'm just using this as an example.)
Since 2.1 code freeze is close and I would like to see this fix included, I suggest to file another issue for the remaining not-quoted unix paths of the scripts.
obrmac: good idea. smsm1: I did try to get all the places where the "quoted form" is relevant. It cannot be used in every case, because some times the quoted form of the path actually causes errors, where non-quoted does not. Also there are situations where a variable might get quoted twice --> errors. The current patch should thus fix the important cases while not causing any new bugs.
smsm1 -> mox: I thought that's what the reason would be after taking a further look at the code. It's great that you have verified what, I ended up thinking would be the issue if we had the fix was applied in other places. See mailing list for build verification info by the buildbot.
Verified good on pj64. James McKenzie
*** Issue 71441 has been marked as a duplicate of this issue. ***
Integrated since ages.