Jump to content
Ketarin forum

{startuppath} not working in global commands


shawn
 Share

Recommended Posts

{startuppath} isn't being replaced properly in global commands, so the following:

echo {category} /// {appname} {version}>> "{startuppath}\Updates.txt"

 

Actually runs as:

echo Utilities /// MyApp 1.0>> "{startuppath}\Updates.txt"

Link to comment
Share on other sites

  • 1 month later...

{root} won't work, since that's the root of the drive. I'm trying to programmatically export my own tailored log to a text file I use for monitoring changes. I would like to be able to make it as portable as possible, which means it needs to write to a child folder of the Ketarin running instance. It won't always be the same path (sometimes it'll be run through a network, mapped drive, USB key, or other methods). I wanted to use ".\" but I'm afraid of the potential for the "." to be misinterpreted as a different path on various operating systems.

Link to comment
Share on other sites

  • 3 weeks later...

Is there a way within the "commands" functionality to access the "startuppath"?

 

I've tried using {startuppath}. Doesn't work.

I've tried using a global variable which is assigned to {startuppath}. That doesn't work.

I've tried using ".\", but that's unreliable based on how Ketarin is started (it's treated as the active directory instead of the application path).

 

Ideally, I'd have the ability to simply use {startuppath} within commands, since what I'm after is a way to replace this type of thing:

echo {category} /// {appname} {version}>> "%HOMEPATH%\Desktop\Ketarin\Updates.txt"

 

With this:

echo {category} /// {appname} {version}>> "{startuppath}\Updates.txt"

 

This would make Ketarin more portable for me. There are times I need to be able to run it across networks (which means there's a different path) or through shell scripts by another user account. In these situations, my options appear to be to either hard-code the path, or duplicate the folder so that the settings can be unique to the specific instance. I would like to avoid duplication as much as possible, of course.

Link to comment
Share on other sites

It is like

{root}

If Ketarin is located in a subdirectory e.g. Ketarin

{root}Ketarin

you have to use it WITHOUT backslash before "Ketarin". It works fine for me.

You should try

{startuppath}Updates.txt

Link to comment
Share on other sites

Unfortunately, none of those are solutions, just restating the problem in different ways.

 

First, I don't really care what the {root} is - I don't want to have to rely on any potentially static information (such as a subfolder or drive letter or other issue) - so "{root}\Path" is simply nonsensical - it requires me to fiddle with it based on how the application is run. That's a fail.

 

And, since {startuppath}, as a function and not a variable, isn't populated in the "command" functionality, I can't use it the way I need to.

 

In order to accomplish what I'm after directly, it looks like I'm going to need to edit *every* template on my list to add a variable that just parses the contents of {startuppath} to relay the information to the command. This would result in bloated templates, duplicated code running unnecessarily several hundred times, and incompatibility with the online database. I'd like to avoid all that if possible.

 

I guess I just don't see more than a couple good reasons for {startuppath} to even be used on the templates themselves (direct extraction or execution being the only justification). And I see no reason for it to be lacking implementation in the global functionality.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.