The official released jar file should be named simply "cryptomator-cli.jar"

[mhogomchungu]

The official released jar file should be named simply "cryptomator-cli.jar"

[mhogomchungu]

I have decided to start distributing cryptomator-cli and to simply call it "cryptomator-cli.jar".

My fork is here[1] and i also added a few things to make it behave more or less like other FUSE based backends SiriKali supports.

[1] https://github.com/mhogomchungu/cli

[overheadhunter]

So why don't you rename it?

[mhogomchungu]

I have a project called SiriKali[1] and people have asked for a cryptomator backend support[2][3] and i have decided to add it for cryptomator-cli when it is using FUSE.

The problem i am facing are:

1. How does SiriKali figure out if cryptomator-cli is installed when SiriKali is running on $RANDOM_DISTRO.
2. if this feature request is implemented, then how does SiriKali figure out what version of crytomator-cli is installed.

The two bug reports i have opened asked for these two things.

Any person who will be creating a front end for cryptomator-cli will want to have a consistent name they can rely on.

Look how simple this[4] line is and imagine how it would be if java executable was dependent on its version.

[1] https://mhogomchungu.github.io/sirikali/
[2] mhogomchungu/sirikali#127
[3] mhogomchungu/sirikali#81
[4] https://github.com/cryptomator/cryptomator/blob/e8d17cfb7b41e3eb8fa3e5083d702d8f01f48087/main/buildkit/src/main/resources/launcher-linux.sh#L3

[overheadhunter]

Ok I see, so you don't bundle cryptomator-cli yourself but rely on it already being installed somewhere? So how do you find out where the jar lays around in the first place?

I think what you really need is a binary accessible via PATH, don't you?

[mhogomchungu]

No, i am not bundling any of the supported backends and ideally, users should install them through their distribution's official channel.

What i want is to set the name of the executable like i do here[1] and then search for it at startup in paths specified here[2]. Java executable is added here[3]

[1] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines/cryptomator.cpp#L53

[2] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines.cpp#L76-L92

[3] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines.cpp#L422-L427

[overheadhunter]

Ok in this case it's not the name of the jar created on this repo that needs to be deterministic, but you need a deterministic executable name that is installed on the user's PC.

Currently there is no such executable name, since we don't provide any kind of installer. cryptomator-cli is just a tool for enthusiasts who download it themselves from this GitHub repo and we have no idea where they save it and what name they give it.

[mhogomchungu]

Ok in this case it's not the name of the jar created on this repo that needs to be deterministic, but you need a deterministic executable name that is installed on the user's PC

Yes.

Currently there is no such executable name, since we don't provide any kind of installer. cryptomator-cli is just a tool for enthusiasts who download it themselves from this GitHub repo and we have no idea where they save it and what name they give it.

Users who download it themselves or distributions that packages it will most likely go with the default name chosen by upstream and set in the download page and the name for the latest version is "cryptomator-cli-0.4.0.jar"[1] and what i am asking is for the "-0.4.0" part to be removed when the next version is out to give a consistent name across versions.

Why was it added in the first place? CLI tools usually don't bundle their version string in their names.

[1] https://github.com/cryptomator/cli/releases/tag/0.4.0

[mhogomchungu]

While here, just though i should mention that i just purchased a version for android to support your effort.

[overheadhunter]

Why was it added in the first place? CLI tools usually don't bundle their version string in their names.

Please don't mix up these two things:

1. Installed tools don't include the version number in their names. That is for the reasons you mentioned above.
2. Downloads usually do include the version numbers. Otherwise there is no way to distinguish what you've downloaded.

If there was an installer foo-installer-1.2.3.exe (version included in filename), it'd be its job to install version 1.2.3 of foo to its destination path C:\whatever\foo.exe (same name for all versions)

The jar in question qualifies as neither. It is not even a binary file. Linux FHS would install such a file under /usr/local/share/cryptomator-cli-x.y.z.jar and put an executable into /usr/local/bin/cryptomator-cli (probably a shell script running java -jar).

[mhogomchungu]

The jar in question qualifies as neither. It is not even a binary file. Linux FHS would install such a file under /usr/local/share/cryptomator-cli-x.y.z.jar and put an executable into /usr/local/bin/cryptomator-cli (probably a shell script running java -jar).

I did not know about this and i think it will solve the problem.