Skip to content
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

fix(stylelint): Shell escape file names/paths #613

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ChristinWhite
Copy link

Problem

Currently, stylelint fails to lint files when there are spaces in the file path. This causes issues for users with spaces in their directory or file names, preventing proper linting of their CSS files.

Solution

This PR wraps file paths with vim.fn.shellescape() to properly handle edge cases where file paths contain spaces or other characters that require quoting or escaping.

Changes

  • Modified the args function to use vim.fn.shellescape() when passing the file path.
  • Updated the error message construction in the parser to also use vim.fn.shellescape().

Testing

Tested with file paths containing spaces:

  • Regular file: ✅
  • File with spaces in name: ✅
  • File in directory with spaces: ✅

Impact

This change ensures that stylelint works correctly regardless of file path structure.

Copy link
Owner

@mfussenegger mfussenegger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this happening on windows?

On linux the processes aren't running in a shell, so shell-escaping not only shouldn't be necessary but would be the wrong thing to do.
On windows it goes through cmd.exe - and if that's causing the problem then I think the special handling there in lint.lua would need to be extended with the escape logic.

@ChristinWhite
Copy link
Author

ChristinWhite commented Jul 4, 2024

I did not test this on Windows but I ran into this on macOS. As soon as there is space anywhere current filename or path the linter would fail. Once I figured out how to construct and log the command I noticed that spaces weren't being escaped nor was the path quoted, when I added the shell-escape stylelint has been linting flawlessly for me with and without spaces.

That said, I would have expected macOS to handle it the same way Linux does, they're generally pretty similar at the shell level.

I am fairly new to Neovim and haven't done a ton of CLI-based linting so I could be making a mistake. How can I be most helpful in solving this issue?

Environment details:

macOS: 14.5 (23F79)
wezterm 20240203-110809-5046fc22
zsh 5.9 (arm-apple-darwin23.0.0)
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1716656478

Configuration:

local linters = {
  stylelint = {
    args = {
      -- Use a default configuration file if one doesn't exist in the project or a parent.
      "--config",
      function()
        local config = vim.fs.find(".stylelint.config.yaml", {
          upward = true,
          stop = vim.fs.dirname(vim.uv.os_homedir()),
          path = vim.fs.dirname(vim.api.nvim_buf_get_name(0)),
        })
        if #config > 0 then
          print("found")
          return config[1]
        else
          print("default")
          local default_config = xdg_config .. "/stylelint/stylelint.config.yaml"

          return default_config
        end
      end,
    },
  },

  -- Other linter configs...
}

local filetypes = {
  css = { "stylelint" },

  -- Other filetypes...
}

function M.config()
  local lint = require("lint")

  for linter, config in pairs(linters) do
    lint.linters[linter].args = vim.list_extend(lint.linters[linter].args or {}, config.args)
  end

  lint.linters_by_ft = filetypes or {}

  local lint_augroup = vim.api.nvim_create_augroup("lint", { clear = true })
  vim.api.nvim_create_autocmd({ "BufEnter", "BufWritePost", "InsertLeave", "TextChanged" }, {
    group = lint_augroup,
    callback = function()
      require("lint").try_lint()
    end,
  })
end

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 this pull request may close these issues.

None yet

2 participants