Slash is inserted before actual KMVAR value


Please, look at the action chain. I try to quote all files from the clipboard and feed them to Sublime Text. As you can see I use "echo" to control transformation result, and all is at exactly expected state – taking the file list and giving it to ST manually works fine.

But KM passes to ST a file list prepended with leading slash (and the list looks like a single file path with very strange name).


(Before quoting of all the content I replace \R with quote-space-quote as far as files in clipboard are placed each one on it's own line)

1 Like

Ok, here is a more complete actions chain. Is there anything else I must supply to clarify this unexpected KM behaviour?

And I have found a way to illustrate KM macro buggy working result: on the screenshot you see both echo command result - and it is valid file path, - as well as a path which was sent to Sublime Text - look at small popup with light background near editor's tab.

What does the clipboard contain? A list of POSIX paths as lines? Does it include a trailing line ending?

What does the filepath variable end up containing?

Because my guess is that filepath looks something like:

"/etc/resolve.conf" ""

which would pass two parameters to Sublime Text, one of which is the empty string and I don't know what that will do.

Not sure to understand your suggestion. Both script output window as well the only opened tab (with full path small popup) in Sublime Text don't present any signs of any additional quotes.

The first regex replacement deals with end of lines, and the last ones are used in clipboard to separate selected files/directories. There is no trailing end of line after the last file name.

What does the clipboard contain?

What does the filepath variable end up containing?

If the clipboard contains a sequence of paths as lines, and if the line ending is at the end of the sequence of lines, then your conversion will, I believe, end up with an additional parameter at the end being an empty path, and it would not surprise me if Sublime Text treats and empty path as "/".

The last screenshot presents an example with the only selected file in clipboard. That are no ends of lines to replace them.

By the way, the quoting aim is just to deal with path's segments containing spaces.

What does the clipboard contain?

What does the filepath variable end up containing?

Not sure how to move further :smile: I have presented all info (here and via support emailing, with words and with screenshots), but still get questions forcing me to repeat. OTOH you are keeping silence regarding sources/proofs of your suggestion about additional empty argument passed to subl. My mind is lost... :wink: As if I don't understand some obvious fact which you think is so obvious is not matter to mention (yes, my English is very ugly, I see).

OK, there are multiple problems.

The first is that your search and replace is adding an extra "" parameter at the end, so you are getting parameters of:

"/etc/resolve.conf" ""

But the bigger problem is that quotes within variables are meaningless, so that when this is processed by echo or by subl, the first parameter is actually:


That is not a valid file name, and because it does not start with ~ or / and there is no meaningful working directory, that is probably why it is being translated in to


in the same way a path like


would get translated in to


So when you set $tmp to

"/etc/resolve.conf" ""

It actually passes two parameters to subl:

  1. "/etc/resolve.conf"
  2. ""

If your path had a space in it, like:

 "/etc/resol ve.conf" ""

it would actually get three parameters:

  1. "/etc/resol
  2. ve.conf"
  3. ""

The quotes in the variable are meaningless, they are just plain characters by that point.

Instead you need to split the input variable into parts actively. The xargs tool is the easiest.

Get rid of all your processing, just leave them as line separated paths, and then use something like:

echo "$KMVAR_filepath" | tr '\r\n' '\0' | xargs -0 /usr/local/bin/subl

Great, thanks, it is the solution! The only thing I have changed is using \n instead of \r\n.

To summarize that obvious fact I was not aware, quotes in environment variables are treated literally on the variables substitution rather than delimiters as it takes place in command line parsing.