[ImageJ-devel] [fiji-devel] Fiji updater operates on what directories and what file types?

Poczatek, Joseph Collin jpoczatek at rics.bwh.harvard.edu
Tue Dec 31 09:56:33 CST 2013


Hi Johannes,

> Almost correct. The file extensions accepted are dependent on the
> top-level directory. In plugins/ for example, .class, .jar, .ijm and
> script extensions are allowed, but not .lut. In luts/, only .lut are
> allowed. In lib/ (which you did not mention), there is no limitation on
> file extensions.
>
> This restrictions are not for dictatorship reasons, BTW, but to prevent
> surprises from incorrect usage of the updater.
Ok, that makes sense. I didn't mention lib/ because it isn't in a fresh
Fiji install. Is it deprecated, or is it sticking around?

After that I got a little confused... Just to talk this out so I'm not
missing something.

>> Am I correct? What I was attempting was to push a 1-2 bash script that
>> was just "ImageJ-linux64 --all-my-special-args..." and having no
>> extension or .sh didn't take.
> Bash scripts cannot be executed by ImageJ, hence it does not make too much
> sense for the updater to ship them. Having said that, you could upload
> them into, say, lib/.

Couldn't you say the same thing about Fiji shipping with a .desktop
file? It's an analogous situation I think. We just want to make it easy
to launch Fiji in a certain way.

>> I can think of several workarounds, the most obvious is to create
>> Fiji.app/scripts/mything.bsh where I guess the worst that could happen
>> is someone tries to run it as a beanshell script.
>>
>> Is there a better way to do this? I can also think of other use cases
>> besides this specific one.
> It is a very dangerous thing to let random people specify the way you run
> things, therefore my suggested way would be to ship the Bash scripts
> separately to the users (so they know they are from a trusted source, and
> so they know to to complain to when their Windows machine has no clue how
> to run Bash scripts).
Maybe I should say that nothing I'm talking about is forced on the
user.  They could still run our plugin from the plugins menu like
normal. Putting a .sh file in lib/ sounds like the best option and we
don't have to use an incorrect extension.  Thanks for pointing that out.

Happy New Year,
Collin





The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.




More information about the ImageJ-devel mailing list