Enhance {{clipboard}} to work with copied files' paths

[Taitava]

At least in Windows, if you select a file in Explorer (= file manager) and copy it with Ctrl + C, the system does not use the regular clipboard to store a path to the copied file. If you in this situation use a shell command with {{clipboard}} in it, you will end up with an empty text instead of a path to the file that should be in the clipboard.

I don't know how this works in Mac. In Linux, if I remember correctly, you get the file path in the clipboard just like you would expect.

I need to think about a way how to provide access to clipboard files. I'd like to define a command that, when executed, it would copy whatever file I have in the clipboard to my Obsidian vault. It would be nice for my cat food database where I collect images of different food brands and ratings done by my cat. 😸

[FelipeRearden]

@Taitava,

Just to let you know that {{clipboard}} of file path works on MacOS as you suspected.

Sorry that it is not working yet on Windows :(

As you know I'm not an expert but I'm facing some issues with pbpaste on Mac and the experts are saying that there is more than one pasteboard from where we can copy things to clipboard on MacOS.

• Maybe this triggers something in your mind.

:)

[Taitava]

As you know I'm not an expert but I'm facing some issues with pbpaste on Mac and the experts are saying that there is more than one pasteboard from where we can copy things to clipboard on MacOS.

Yes I had a clue that also Windows might have different clipboards for different things. But good to know that the file copying/pasting works on Mac.

About different clipboards, I remember now that Linux has two clipboards: One is the normal copy/paste clipboard, and a second one is for text that is selected in a command line terminal window. You just select text in a terminal window and it becomes available in a secondary clipboard, but you can't access it with Ctrl+V, you need to use some other keyboard shortcut to paste it.

Things todo:

• On Mac copying a file to clipboard makes the path available in {{clipboard}} correctly, so no need to do anything on Mac. Thanks @FelipeRearden for this information! 🙂
• Linux: Test in Obsidian that if I copy a file to the clipboard, then {{clipboard}} should have the file path.
• Windows: Study require("electron").clipboard.read() to see if it can read file paths. At least it's documentation says that it can read image data that is copied to the clipboard.

If I need to create new versions of {{clipboard}}, I will probably consider using the same variable and adding a parameter to it: {{clipboard:WhatWeWant}}. WhatWeWant should be substituted with: file_path if we want to read a file from the clipboard, text for normal cases (or you can omit the parameter, and a simple {{clipboard}} will default to the text mode). This allows new options to be added in the future, if we learn about new clipboard types. These example parameters are not final, and they may change. Text mode will also support file paths in Mac just the way it does currently, I'm not going to change that in any way. So mainly these additions will benefit Windows, but if needed and possible, we can add Mac related clipboard modes too.

[Taitava]

I found a couple of libraries that can read file paths from clipboard:

• https://github.com/alex8088/clipboard-files
• https://github.com/kenan2002/electron-clipboard-ex

But I was not able to load them correctly. I was able to npm install them, but I don't know how to make Obsidian load them.

[Taitava]

Here is something regarding using node packages in Obsidian plugins, but I'm still confused: https://forum.obsidian.md/t/how-to-properly-install-an-external-library-for-plugin-development/8381/2

[Taitava]

Hi @FelipeRearden , can you test on Mac to copy multiple files same time to clipboard and then see what {{clipboard}} gives you, please? I'm mainly interested to know, how the file paths are separated from each other. Thanks! 🙂

[FelipeRearden]

Hello @Taitava !!!

Sure! Take a look at this image:

On MacOS you have to use " " for files and filepaths if they have blank lines

As you can see, each file is placed at a different new line.

Is this what you were looking for? Let me know if you need another test :)

Have a great day!

[Taitava]

I think this is what I was looking for, thank you! But I didn't quite understand the first example, it only lists one file (Feature) but the text says there should be two? But at least the second example shows two files, and like you said, each one of them is on their own line - this is what I was looking for.

So I assume, on Mac you can expect to have multiple file paths to be separated by a linebreak in the clipboard. I'm not totally sure, but this might cause problems if someone tries to e.g. move two files that are copied to clipboard to a folder like this: mv {{clipboard}} destination_folder (let's assume here that the filenames do not contain any space characters, so we don't need to think about " quotes in this example). If the clipboard contains two files, then the real shell command would become like this:

mv filename1.md
filename2.md destination_folder

The linebreak would definitely break the command in normal terminal, but I do not know if it breaks the command when Shell commands executes it, but I assume that it does break.

Just to make sure, did you get directory paths to your files (like /path/to/INP.md), or only the file names? At least your image contains just the file names, so I assume {{clipboard}} did not give you precise paths. (And just a side note: when I ask about file names/paths, or any other results, always feel free to leave out any possible personal information. E.g. a full path to an Obsidian vault might contain personal info (e.g. Obsidian vault name) so I don't want to ask anything that would be too personal).

My idea is to try to find a reliable way to refer to files in clipboard via the {{clipboard}} variable. So far I've come to think about the following requirements:

• {{clipboard}} should give absolute file paths, not only the file names.
• A user needs to be able to define the separator: in some cases linebreak is good, but sometimes it should be a space , sometimes comma ,, sometimes comma and space together , , or whatever characters the users wants to use.
• A user should be able to decide if the filenames should be encapsulated in single/double quotes, or no quotes at all. If the user had a single file in the clipboard, this would be easier: the user would simply write the quotes in their shell command, but now that there can be multiple files, the user cannot use quotes around {{clipboard}}, because it would quote multiple filenames together, eg. "{{clipboard}}" can become "filename1 filename2 filename3", when it should be "filename1" "filename2" "filename3". But this is at least partly overlapping with Variable values should be escaped #11 .

My outcome is that even though you can get files in some format out of {{clipboard}} on Mac, an improvement is needed. The two libraries I meantioned in my previous message do support Windows and Mac, but not Linux. With one of those libraries, I should be able to implement this feature for both Windows and Mac. Linux support might be added later, as the libraries' developers are willing to support Linux too if they will find a way for it in the future.

In case I didn't mention this earlier, I'm thinking about adding a "mode" argument to {{clipboard}}:

• {{clipboard}}: Would work like it currently works, give the normal clipboard content.
• {{clipboard:files:separator}}: Would give the file paths, and separator could be a freely decided character/multiple characters.
• {{clipboard:file}}: Would be a simpler version that only gives first file from the clipboard, even if there are many.
• This is just a draft idea.

Huh, sorry for the wall-of-text!

[FelipeRearden]

Hello @Taitava !!!!

But I didn't quite understand the first example, it only lists one file (Feature) but the text says there should be two? But at least the second example shows two files, and like you said, each one of them is on their own line - this is what I was looking for.

I was trying to show that on MacOS, you have to use “ ” if you have a file_name or file_path with (space):

• Feature(space)Request.md
• INP.md

Fist example show that when there is only {{clipboard}}, MacOS will cut the text when see a

• Feature

With “ {{clipboard}}” we have the desired result

• Feature(space)Request.md
• INP.md

Just to make sure, did you get directory paths to your files (like /path/to/INP.md), or only the file names? At least your image contains just the file names, so I assume {{clipboard}} did not give you precise paths.

I copied just the files_names :)
Let me known if you need me to copy the file_paths too (I think we can’t copy more than one file_path but I can try)

(And just a side note: when I ask about file names/paths, or any other results, always feel free to leave out any possible personal information. E.g. a full path to an Obsidian vault might contain personal info (e.g. Obsidian vault name) so I don't want to ask anything that would be too personal).

I have the same principle as you :) thanks for your comment.

My idea is to try to find a reliable way to refer to files in clipboard via the {{clipboard}} variable. So far I've come to think about the following requirements:

Additional thing to talk to you that I remember reading this: on MacOS the file_path:absolute starts with \ —> this way I have to use this on Shell Command: “{{file_path:absolute}}”

• {{file_path:absolute}} = Users\login\vault\folder\MyNote.md;
• MacOS file_path:absolute = \Users\login\vault\folder\MyNote.md

A user should be able to decide if the filenames should be encapsulated in single/double quotes, or no quotes at all. If the user had a single file in the clipboard, this would be easier: the user would simply write the quotes in their shell command, but now that there can be multiple files, the user cannot use quotes around {{clipboard}},

This is a fantastic idea !!!! I haven’t thought about multiple files yet, but it is a something important and you are right about the “ ” issue.

In case I didn't mention this earlier, I'm thinking about adding a "mode" argument to {{clipboard}}:

This is a AMAZING idea !!!!! These ‘modes’ could be useful not only for multiple file_paths, but for text in multiple lines too

• a separator could be a \n Line break, adding one line break after each line from clipboard

Huh, sorry for the wall-of-text!

I know this feeling: when we get excited about something we can’t stop writing :)

---

This is gonna be an amazing feature in the future. Let’s keep talking :)

Have a great day!

[Taitava]

I was trying to show that on MacOS, you have to use “ ” if you have a file_name or file_path with (space):

Ah, now I understood it when I read it again one more time. Thanks! 🙂

I copied just the files_names :)
Let me known if you need me to copy the file_paths too (I think we can’t copy more than one file_path but I can try)

It's enough that I know {{clipboard}} gives file paths too, no need to copy. 🙂

Additional thing to talk to you that I remember reading this: on MacOS the file_path:absolute starts with \ —> this way I have to use this on Shell Command: “{{file_path:absolute}}”

• {{file_path:absolute}} = Users\login\vault\folder\MyNote.md;
• MacOS file_path:absolute = \Users\login\vault\folder\MyNote.md

That seems like a bug! But the character is / instead of \. Windows uses \ (and I hate it because it's harder to type on a Finnish keyboard 😆 ). Can you create an issue about this, please? For the content you can just use what you wrote above. I'll have to see if this is a bug in Obsidian's API or if I'm using the API incorrectly.

This is a fantastic idea !!!! I haven’t thought about multiple files yet, but it is a something important and you are right about the “ ” issue.

Thanks! 🙂 I have to say that I didn't think about multiple files, too, when I first started to thinking about how {{clipbaord}} behaves with files. I had a need to use it for one file at a time. But in programming, when you start to think about simple things, you'll soon notice that you'll have to consider all sorts of non-simple use cases.

These ‘modes’ could be useful not only for multiple file_paths, but for text in multiple lines too

• separator could be a \n Line break, adding one line break after each line from clipboard

Hmm, currently \n does not work at least on Windows, so I created a new conversation about linebreaks over here.

I know this feeling: when we get excited about something we can’t stop writing :)

Exactly! 🙂

This is gonna be an amazing feature in the future. Let’s keep talking :)

Have a great day!

Thank you and have a great day too! You are super! 🙂

[FelipeRearden]

That seems like a bug! But the character is / instead of . Windows uses \ (and I hate it because it's harder to type on a Finnish keyboard 😆 ). Can you create an issue about this, please?

Done #44 here :)

Sorry for the \ and / 🙏 you understand my mistakes :)

You are super! 🙂

Thanks, I'm just following your path :)

Have a great day!

[Taitava]

Thanks, same to you! 🙂

[Taitava]

And one more mode: {{clipboard:count_files}} could give an integer telling how many files there are currently copied in the clipboard.

[FelipeRearden]

Maybe too:
{{vault:count_files}}
{{folder_path:absolute:count_files}}

Just adding all possibilities

[Taitava]

Those are nice ideas, but now that I've been thinking a lot about these {{clipboard}} issues, it has come to my mind that {{clipboard}} is actually a redundant variable. It can be replaced with natural shell commands.

• {{vault:count_files}}: Can be replaced with ls {{vault_path}} | wc -l (Linux).
• {{folder_path:absolute:count_files}}: Can be replaced with ls {{folder_path:absolute}} | wc -l (Linux).
• {{date:format}} can be replaced with something. But at least {{date:format}} is good so that it offers the same date format syntax as other Obsidian features.

So, when thinking more specifically, variables should concentrate to get information from Obsidian (= information that cannot be achieved outside of Obsidian). Good example: {{selection}} (even though it does not work in preview mode 🙁 ), or currently active file's name.

In this light, maybe {{clipboard}} should not exist at all. I need to think about will I keep it, or remove it before 1.0.0. But for now, it can stay.

A redundant variable may defend it's existence with ease of use, however. But then it has to be something that is needed often.

[FelipeRearden]

In this light, maybe {{clipboard}} should not exist at all. I need to think about will I keep it, or remove it before 1.0.0. But for now, it can stay.

Of course I will respect your decision because I know you want the best for everybody!!!

In my humble opinion, {{clipboard}} the way that is now is a great variable. I use {{clipboard}} a lot to paste content (since don't know how to make pbpaste work)

I have this workflow: I have a note that is called INP.md (Non processed Insights) that lives in my right sidebar for quick access.

• I stock everything there and deal with it later;
• Everytime I have an idea or something to remember that is not related to something that I'm working now, I just starting typping what I need to remember and use this shell command echo "\n{{clipboard}}" >> "/Users/login/vault/folder/INP.md" to paste this insight in the INP note.

---

Everyday we are finding new workflows that needs Shell Commands to exist. My fear is that we lost the opportunitty to use {{clipboard}} to workflows that we don't know that exist yet :)

Lets keep talking :)

Have a great day @Taitava !!!

[Taitava]

In my humble opinion, {{clipboard}} the way that is now is a great variable.

And in the way {{clipboard}} currently is, it doesn't even have a huge codebase, just 15 lines (4 that are most significant). So it should not be a pain to keep it and maintain it.

Improving {{clipboard}} to give file paths, however, is starting to feel like a bit too much work in an area that is not in the core of this plugin. I tried to look at those two libraries that I meantioned earlier, but I was not able to get them installed properly, and they seem to contain C++ code, so maybe they do not provide a pure JavaScript library. Obsidian plugins cannot run anything else than JavaScript. Maybe there would be a way to read file clipboards in JS too, but it would requre more exploring. So I think I'll have to put these enhancement ideas on hold at least for now. I'll move this discussion to the On hold category.

I use {{clipboard}} a lot to paste content (since don't know how to make pbpaste work)

Shouldn't something like this work: echo "\n" >> "/Users/login/vault/folder/INP.md" && pbpaste >> "/Users/login/vault/folder/INP.md"? Or pbpaste >> "/Users/login/vault/folder/INP.md". I'm not sure, though.

[FelipeRearden]

And in the way {{clipboard}} currently is, it doesn't even have a huge codebase, just 15 lines (4 that are most significant). So it should not be a pain to keep it and maintain it.

Thanks for keeping my beloved variable 🙏

Improving {{clipboard}} to give file paths, however, is starting to feel like a bit too much work in an area that is not in the core of this plugin.

100% agree with you. In this specific case we don't have to complicate something that is simple. Less is More :)

Shouldn't something like this work: echo "\n" >> "/Users/login/vault/folder/INP.md" && pbpaste >> "/Users/login/vault/folder/INP.md"? Or pbpaste >> "/Users/login/vault/folder/INP.md". I'm not sure, though.

I will try and get back to you. Thanks for one more help :)

Have a great day!

[Taitava]

This clipboard file path thing has received an answer in Obsidian's forum by renmu:

import { clipboard } from "electron";

  isCopyImageFile() {
    let filePath = "";
    const os = this.getOS();

    if (os === "Windows") {
      var rawFilePath = clipboard.read("FileNameW");
      filePath = rawFilePath.replace(
        new RegExp(String.fromCharCode(0), "g"),
        ""
      );
    } else if (os === "MacOS") {
      filePath = clipboard.read("public.file-url").replace("file://", "");
    } else {
      filePath = "";
    }
    return this.isAssetTypeAnImage(filePath);
  }

I haven't tried this code yet. Seems like it should work on Windows and Mac. If a solution for Linux will be found, I think this discussion can be moved back to Ideas (now it's in Ideas - on hold).