Best way to "shortcut" a singularity command?

[Jonathan Greenberg]

Ok, so let's say (because its true) I have program that needs wine to run, called "myexe.exe".  Right now, I have to:

singularity exec wine myexe.exe

I'm trying to figure out the "right way" to reduce this so on my runtime system I just:

myexe.exe

It seems to begin with, I can create an "app" that runs "wine myexe.exe" from within the singularity def (easy enough).

Now, is there an "official" way to "get rid" of singularity exec in the command?  I assume using "alias" but is there some way to get this set up within the definition file itself?  Or it would need to be run by each individual singularity user?

--j

[v]

If you use a runscript, and the runscript calls "exec wine myexe.exe" in the container, then outside the container you should be able to do:

singularity run container.simg

and actually, if you just execute the container, this does the same thing:

./container.simg

the reason being if you look at the head of the file, you see this:

#!/usr/bin/env run-singularity

Which tells your system to execute the file using the run-singularity executable, which is the other executable in the singularity bin. 

If you are needing to use "singularity exec" because you only have one runscript/entrypoint and want to define more, then the single runscript isn't sufficient and you would do well to put your stuffs in a Scientific Filesystem (SCIF):

And then to run your different apps you could do like:

./container.simg run ping

./container.simg run pong

./container.simg run oregon-trail

etc.

--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

--

Vanessa Villamia Sochat
Stanford University '16

(603) 321-0676

[David Godlove]

Hi Jonathon,

+1 what V said.  Also if you want to expose multiple applications within your container and basically "pretend" they are all installed directly on your host system, you can write a wrapper script like this and make symlinks to it for each app you want to "install".

#!/bin/bash

# if you want to bind some host directories...

# export SINGULARTY_BINDPATH=/some,/dirs,/to,/bind

dir=$(dirname  "$0")

cmd=$(basename "$0")

arg="$@"

singularity exec $dir/image $cmd $arg

Check out this repo for an example on how to make that work.  After running it and adding the correct directory to your path, it should seem like the programs fortune, cowsay, and lolcat are installed directly onto your host even though they are running within a container.  

I know that the NIH uses this approach to install apps within containers on Biowulf.  Then users can interact with the applications without touching Singularity. 

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.

--

Vanessa Villamia Sochat
Stanford University '16

(603) 321-0676

[Rémy Dernat]

Hi,

You can also use environment modules or aliases.

Best regards.

To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.

[Dmitri Chebotarov]

Hi, 

environmental module example for R:

('crun' alias allows to run some odd commands which are not aliased)

"

...

module load singularity

set CNT_IMAGE /singularity/images/R-3.4.1.v4.img

setenv SINGULARITYENV_PATH /opt/R/3.4.1/bin

set-alias R "singularity exec $CNT_IMAGE /opt/R/3.4.1/bin/R \$*"

set-alias Rscript "singularity exec $CNT_IMAGE /opt/R/3.4.1/bin/Rscript \$*"

set-alias crun "singularity exec $CNT_IMAGE \$*"

set-alias cbash "singularity shell $CNT_IMAGE"