[Swift-devel] Re: Finding apps via $PATH

[Ben Clifford]

Omit the path in a tc.data entry (eg say echo instead of /bin/echo) and 
$PATH will be used to look up the executable. This is in SVN head and also 
in the 0.7 release.

Related, if you want to add stuff to the remote path rather than 
completely reset the remote path losing defaults, look at the PATHPREFIX 
env profile in the user guide.

On Tue, 13 Jan 2009, Michael Wilde wrote:

> was: Re: [Swift-devel] fun with osg
> 
> Ben, could you (re)post info on how to do this:
> 
> > There also remains the problem of application location and deployment; in
> > my playing today I used default $PATH method of finding my test executable
> > (touch) - this is still hard, though I have some other notes to write
> > about that elsewhere.
> 
> Does it work in the current rev?
> 
> - Mike
> 
> On 12/9/08 7:57 PM, Ben Clifford wrote:
> > I played some with Mats Rynge at RENCI today.
> > 
> > He modified some code he already had to output sites.xml based on the OSG
> > ReSS information system.
> > 
> > This made it straightforward to submit jobs to sites that are in OSGEDU (the
> > only OSG VO that I am a member of) running executables that are already on
> > the system $PATH.
> > 
> > However, of the 13 sites advertising that they support OSG EDU, only two are
> > actually able to run Swift jobs this afternoon.
> > 
> > I just got setup to submit jobs to the OSG Engagement VO; this changes the
> > range of sites available, but also opens up some more opportunity for
> > narrowing down the range of available sites as the Engagement VO has a
> > richer set of site availability information that can be used to construct a
> > more-likely-to-work sites.xml file.
> > 
> > Of the two working-and-published OSGEDU sites, I also tried running with
> > coasters; that failed dismally on both - in the case of one site, the fork
> > job manager was the ever-more-common ManagedFork jobmanager, which appears
> > unable to be able to execute the head jobs. The other site ran the head job
> > but worker nodes could not communicate properly with that. so frrrr.
> > 
> > There also remains the problem of application location and deployment; in my
> > playing today I used default $PATH method of finding my test executable
> > (touch) - this is still hard, though I have some other notes to write about
> > that elsewhere.
> > 
> > Replication seems to do a good job with failing sites, although not a
> > completely perfect job. One site takes jobs to the karajan Active state and
> > then stays there forever. Replication, as presently implemented, doesn't
> > cope with that.
> > 
> > So nothing particularly new - OSG as usual...
> > 
> 
>