Skip to content

Unable to open files with dollar ($) character #863

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
daniele-orlando opened this issue Feb 20, 2019 · 4 comments · Fixed by #895
Closed

Unable to open files with dollar ($) character #863

daniele-orlando opened this issue Feb 20, 2019 · 4 comments · Fixed by #895
Milestone

Comments

@daniele-orlando
Copy link

daniele-orlando commented Feb 20, 2019

MacVim: 8.1.950 (155)

MacVim is unable to open a file when it is invoked from Finder with a file name or a parent directory contains the character $.
Example: project/$config/main.yml

Steps to reproduce

  1. mkdir -p 'test/$config'
  2. echo "test" > 'test/$config/test.txt'
  3. open -a Finder .
  4. From Finder, try to open the file with MacVim double clicking the file name (the file type must be associated with MacVim)

or download the attached archive.

Expected result

test.txt file should open inside MacVim displaying test content.

Actual result

MacVim opens a not existing file test//test.txt displaying an empty content.

@ychin
Copy link
Member

ychin commented Feb 22, 2019

Hmm I'm having some issues reproducing this. It almost seems to me that someone is doing a variable substitution for $config here. What if you just name your file test_$_file and test_$var_file?

Also, what OS are you using? Does this not happen if you load the file from command line (i.e. mvim <filename>)? Do you have any plugins that you think could interfere with this?

@daniele-orlando
Copy link
Author

daniele-orlando commented Feb 22, 2019

The problem arises when the dollar sign is in the directory name.
To reproduce, please follow literally the Steps to reproduce or download the attached archive.

@ychin
Copy link
Member

ychin commented Feb 23, 2019

Yes I did follow the steps literally which is why I asked the followup questions to help identify why I couldn't reproduce the issue. Did you have a chance to test whether file names with $ work?

Also, what macOS version are you using? Did you only see this issue when you double click on the file or when you drag the file to the dock's icon too?

Edit: Actually, nevermind. I reproduced it! I will need to take a look.

@daniele-orlando
Copy link
Author

Yes, file names with $ character work as expected, no problem with them.

@ychin ychin added this to the snapshot-156 milestone Feb 23, 2019
ychin added a commit to ychin/macvim that referenced this issue May 22, 2019
This fixes a whole host of related issues in MacVim that fails to
properly sanitize filenames when opening files using the GUI (e.g.
drag-and-drop, file type associations, etc). The core issue came from
the fact that the code used to rely on constructing Vimscript commands
to send to code Vim to parse using `addInput` (e.g. `:tabe <filename>`).
This was convenient and fast to add new feature but requires properly
sanitizing filenames (since that's an arbitrary user input). It used a
bespoke function `stringByEscapingSpecialFilenameCharacters` but it
didn't fully work ('$' would not be escaped so it would be interpreted
as a Vim variable) for all filenames.

One solution should be to use Vim's fnameescape() utility, but it
doesn't fully solve all edge cases. For example, if we hae a newline in
a filename (which is admittedly weird) it will still break the Vimscript
parsing.

Better solution is to simply construct the raw Ex commands in C
manually. It forces more tie-in to Vim's internals but is the most
robust way to arbitary filenames. Replace all usage of
stringByEscapingSpecialFilenameCharacters with this method:

* `handleOpenWithArguments:` is used by drag-and-drop and opening files
from GUI, so fix that to construct Vim function calls. Also fixes some
weird bugs in existing behavior (e.g. if you drag multiple files in but
one of them is opened alrady, it used to choose the wrong tab to do the
`sall` split in. Now just make sure to make a new tab).

* Dragging files to tab bars. MacVim has a special behavior where
dragging files to tab bars will open files in that particular tab.
Consolidate the behavior to use `handleOpenWithArguments` as well. Also
fix an issue where previously it would forcefully stomp whatever buffer
you had in that tab even if it had unsaved changes.

* Misc cases: New File Here macOS service and a "open first file if
exists already" functionality also need to be fixed. For these two
cases, make new MMBackend handlers just for simplicity as they aren't
doing anything complicated.

For future TODO:
- Implement tests for this when new testing infrastructure is up for
testing MacVim-specific functionality.

Fix macvim-dev#863.
ychin added a commit to ychin/macvim that referenced this issue Jun 11, 2019
Vim patch 8.1.1517

Security Fixes:

- Fix modeline security vulnerability (CVE-2019-12735). macvim-dev#898 (fixed in
  Vim 8.1.265)

Features:

- Add new option 'MMTitlebarAppearsTransparent' that will make the title
  bar transparent and use the background color in the color scheme
  (10.14 or above only). macvim-dev#888

Fixes:

- Fix filename parsing error when opening a file with special characters
  like '$' in file path. macvim-dev#863
- Fix blurry I-beam mouse cursor. macvim-dev#755
- Fix silently failing to save a file when conversion error is present.
  macvim-dev#671. (Vim 8.1.1349)
- Fix failing to save to a network shared SMB folder macvim-dev#861.
  (Vim 8.1.0957)

Misc:

- 'guitablabel' can now be set in .vimrc, without MacVim overriding it.
  macvim-dev#899

Targets macOS 10.8+

Script interfaces have compatibility with these versions:

- Lua 5.3
- Perl 5.18
- Python2 2.7
- Python3 3.7
- Ruby 2.6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants