Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#10119 closed Bug report (fixed)

OS X Filetype Association setting does not allow spaces in app name

Reported by: David Fonseca Owned by:
Priority: normal Component: FileZilla Client
Keywords: Settings File Association Cc:
Component version: Operating system type: OS X
Operating system version: 10.9.5

Description

When I try to create a Custom Filetype Association in the settings, FileZilla strips out the space when I try to specify

php "/Applications/Sublime Text.app"

. I get a pop-error window which reads:

Failed to validate settings
Associated program not found:
"/Applications/Sublime

I've tried entering the following different specifications:

php "/Applications/Sublime Text.app" -open
php /Applications/Sublime\ Text.app -open
php ""/Applications/Sublime Text.app"" -open
php '/Applications/Sublime Text.app' -open
php "/Applications/Sublime\ Text.app" -open
php "/Applications/Sublime\\ Text.app" -open
php /Applications/Sublime\\ Text.app -open

(As well as other variations without the "-open") Interestingly, double quotes and double backslash got VERY close.

Since there are work-arounds (I believe), this is not a barn-burner. It may be a documentation issue, I just have not able to google an answer that works.

BTW, cut'n'Paste is very quirky /and/or not working in this settings dialog as well as the error message window.

...Wait a minit! Now the double quote double back slash does not preserve the space. I swear it did-- Is this related to the cut'n'paste issue? I must be loosing my mind!

Change History (6)

comment:1 by Tim Kosse, 6 years ago

Status: newmoreinfo

Please check that you are using the correct double quotes, namely the "Unicode Character 'QUOTATION MARK' (U+0022)"

Some users, when typing the double quote key get other characters, e.g. Unicode Character 'RIGHT DOUBLE QUOTATION MARK' (U+201D) or Unicode Character 'DOUBLE PRIME' (U+2033).

By the way, why do you add -open? If you add it because it is in the example, the example argument could for example also be -chickensoup

comment:2 by David Fonseca, 6 years ago

I was primarily using whatever the Mac keyboard gives me when I mash down on the shifted right single quote key between the colon/semi-colon key and the Return key. In any case, when I bring up the Mac Character viewer, and cut’n’paste from the character it comes up with for u+0022 (which gives me the following string:

"
QUOTATION MARK
Unicode: U+0022, UTF-8: 22

I then deleted all of the human readable crap, and left the double quotes I used to surround the file spec. That got me a new error reason:
Improperly quoted association.

BTW, as I mentioned before, the behaviour of this app and cut'n'paste is very bizarre. When I ginned up a line in my Mac terminal for

"/Applications/Sublime Text.app"

Pasting it into the custom filetype associations box retained the custom forground and backgound colors of my terminal. Even more bizzarely, if I paste using Command-v, it looks like it uses the font or font-size FileZilla specifies. If I paste using the right-click on the mouse, it retains the font/font-size used by my terminal. In both cases I get the funky colors.

I went back and pasted the double quote using the mouse, and it did not seem to make a difference, but frankly at this point I don't trust Filezilla's handling of paste to behave the way I expect, so I am not even confident that you are getting a U+0022 when I paste a character copied out of the character viewer.

As for your backhanded help about using -open, well of course I am using the line as specified in the example. I did try it without, but lets face it, this command is not even getting that far yet in the parsing code yet. The example suggests using -open, and you can be sure that if I didn't use it, and it was required, you would be very unhappy with me for wasting your time.

comment:3 by Tim Kosse, 6 years ago

Status: moreinfonew

Bizarre. I don't know why the edit field is accepting rich input. It's not mark as rich edit field.

comment:4 by Tim Kosse, 6 years ago

It's a bug in wxWidgets, multi-line text edit fields unfortunately are set as rich text edit fields.

I've created a simple patch for this issue: http://trac.wxwidgets.org/ticket/16805

comment:5 by Tim Kosse, 6 years ago

Resolution: fixed
Status: newclosed

comment:6 by David Fonseca, 6 years ago

Thanks for looking in to this!

-Dave

Note: See TracTickets for help on using tickets.