how to use an environment variable in a path to a file in an annotation

[pglaser-engineer]

Hi.

I am using taskopen v1.1.5 297 b9721f5 in two different environments:

• macos Big Sur
• Debian 10 running virtually in chromeos

I would like to use taskopen to manage not only http links and Notes links, but also links to my own markdown files, which I maintain in vimwiki. In order for this to work in macos, I had to set FILE_CMD to vim: in macos, the vanilla open command doesn't know how to open .md files.

I use my markdown files on both systems and have an extensive set of environment variables to make things work in both places.

The only problem with the annotations as I now add them is that they use an absolute hard coded path, for example:

/Users/docs-base/mkdn/03_tchn/sysi/mylatest_file.md

The actual path on my second system will be different, and so opening these annotations on the other system will not work without using an environment variable in my file paths.

I tried to solve this problem by creating an alias function to annotate tasks with these file links: it writes the path to the file with the correct environment variable. I then end up with an annotatiion that uses a path like this:

$MKDN_ROOT/03_tchn/sysi/mylatest_file.md

In order for taskopen to recognize this as a legit file link, I had to modify FILE_REGEX as follows:

 FILE_REGEX="\$|\.|\/|~" 

When I try to open this link in taskopoen, it doesn't expand the environment variable: it is looking for a directory that is literally named $MKDN_ROOT

When I used taskopen -L to see how it would open the link, I noticed that my link was enclosed in single quotes whereas the links to Notes -- which use environment variables quite handily -- are in double quotes. I experimented with various means of making my links have doouble quotes (escaping double quotes, escaping two double quotes) all to no avail: taskopen appears to be quite insistent on single-quoting these links.

I am hoping that I am overlooking something simple in all this (I'm quite new to shell scripting) or that there is a different solution through configuration.

Thanks so much -- I love this tool! --Phil

[jschlatow]

Hi Phil. Unfortunately, environment variables from your shell are not passed along to the shell that taskopen spawns.

I suggest you add a CUSTOM1_REGEX and CUSTOM1_CMD to your taskopenrc. With the former, you can match on .md files in your annotations without touching the FILE_REGEX. Once the CUSTOM1_REGEX matched, the CUSTOM1_CMD is executed. I think it's best if you used a helper script in your CUSTOM1_CMD in which you then build the correct absolute path from the annotation that only specifies the path relative to $MDKN_ROOT.

Alternatively, you may have a look at taskopen 2.0. I haven't released that version yet because I still need to update the manpages. Nonetheless it's documented in the wiki and much easier to configure in my opinion. If you want to give it a try, be my guest.

[pglaser-engineer]

Hi Johannes,

Thanks so much for your prompt reply. I did not realize that v. 2.0 is so far along. That is very exciting. I look forward to it at some point after it's merged to master, but for now, I'll need stick with the current version.

I discovered a different way to meet my objective. Rather than use an environment variable to reference the root directory of my md files, I am using a symlink -- /usr/local/mkdn_root to that directory. As long as I set up that symliink correctly on both systems, the path to a file in the annotations is the same: /usr/local/mkdn_root/03_tchn/myfile.md. Opening the annotation this way is a little slower, but for now I'm happy with it.

As for CUSTOM1_REGEX and CUSTOM1_CMD, I do want to use these for my markdown files, and leave the default command at open or xdg-open. After many attempts, however, I could not get the regex to match my file paths.

I tried a number of different regex expressions, and tested them all against my file paths in an online regex tester, but they just don't match the files in taskoopen. For example:

CUSTOM1_REGEX=".*\.md"
CUSTOM1_CMD="vim"

did not recognize /usr/local/mkdn_root/03_tchn/sysi/sysi_my_file.md, even though it worked just fine in a regex test application.

I could not find similar examples the taskopenrc file comments.

Is there something else I need to do when specifying the regex for a custom command, or am I missing something obvous (I'm fine with a bit of embarassment if it saves me more trial and error :-)

Many thanks! --Phil

[jschlatow]

Hi Phil,

I'd guess that maybe your FILE_REGEX already catches the annotation. Would you mind posting the output of taskopen -V so that I may have a look at your configuration?

[pglaser-engineer]

Hi Johannes,

Yes, that idea popped into my head first thing this morning. It hadn't occurred to me before that that there is an order of precedence to how these regexes are applied. But, logically, of course, there would have to be an order.

So now I have:

FILE_REGEX="(?!(\/*.*)\.md)(\.|\/|~)"

CUSTOM1_REGEX=".*\.md"
CUSTOM1_CMD="vim"

Which now yields:

    % taskopen -L 183

    1) vim '/usr/local/mkdn_root/03_tchn/sysi/my_markdown_file.md'
    2) open '/docs/admin/new_guidelines.docx'

I don't know what kind of customization features have been added in v. 2.0, but it strikes me that because in most cases the matching is done based on file type, it would be useful to have a dictionary like:

{ "md" : "vim",
  "pdf": "zathura",
  "*" : "default"
}

(Sorry for slipping in a feature request -- I couldn't help myself).

Thanks again for your prompt attention. I appreciate it. --Phil

[jschlatow]

No worries. I appreciate your feedback.

Unfortunately, there are multiple aspects that determine the type of a file. On the one hand, there is the extension (which you already mentioned). On the other hand, there is also the mime time. I'm not sure about macos, but on Linux xdg-open bases its decisions on the mime type. So far, I rather tried to re-use what's already provided via open/xdg-open and don't re-implement similar features in taskopen.

I know that there are cases in which we want to override the default system policy. In fact, taskopen adds more aspects to the aforementioned such as the location of files or special keywords (e.g. 'Notes'). At the moment, I'd therefore regard your feature request as something that is probably better dealt with by an extension script that is executed once taskopen's regexes categorised the annotation as a file path. Think of it as an improved/modified variant of open.

Please understand that I'm hestitant with your feature request because the main motivation behind taskopen 2.0 was to reduce the complexity of its configuration and reduce the number of corner cases. Although I like the idea of a simplified configuration syntax, it only addresses a small subset of what taskopen is supposed to do. This is why I don't have a good idea how to integrate this without raising complexity and reducing clarity.

What's your opinion on this?

[pglaser-engineer]

What you are saying makes good sense. In theory, as you say, xdg-open and open should know what to do with a variety of file types (mime-type had not occurred to me). My situation only arose because of the peculiarity on mac that the open command doesn't know what to do with .md files. There is a way to change it's behavior with an applescript but I think I'd rather spend my brain's computing cycles on getting my arms around python and shell scripting. Since xdg-open and open are likely to work in most cases, handling the edge cases as I did with the command/regex option and the symlink is perfectly fine.

Thanks again -- I appreciate the dialog :-) Phil

[jschlatow]

You're welcome, I also appreciate the dialog.

I'm closing the issue now but feel free to post any further questions here or in a seperate issue.