Best Approach for Included Script Files

Hi,

I'm seeking suggestions on the best way to #include script files. There are
many possible ways of doing this that I know about, but what do you think is
best?

I'm leaning towards creating an environment variable as part of an
installation script and then using that value to build an absolute path name
that I can invoke.

Please point me to other discussions on this topic if this has come up
before ..

Thanks in advance,
Adam
http://www.codeplex.com/psexpect PowerShell Scripts for Testing
http://testfirst.live.spaces.com PowerShell for Testers

Not sure I understand. Are you needing something other then dot-sourcing
(i.e. . .\script.ps1) ? tia

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


"Adam Geras" <AdamGeras@discussions.microsoft.com> wrote in message
news:F2F6D024-5721-4A89-BB72-A1A301A3C548@microsoft.com...
| Hi,
|
| I'm seeking suggestions on the best way to #include script files. There
are
| many possible ways of doing this that I know about, but what do you think
is
| best?
|
| I'm leaning towards creating an environment variable as part of an
| installation script and then using that value to build an absolute path
name
| that I can invoke.
|
| Please point me to other discussions on this topic if this has come up
| before ..
|
| Thanks in advance,
| Adam
| http://www.codeplex.com/psexpect PowerShell Scripts for Testing
| http://testfirst.live.spaces.com PowerShell for Testers

No, that works fine, but I don't want to use the relative path name. I want
this script that is to be 'installed' in one place, and then include it from
several other scripts in (variable) locations.

"William Stacey [C# MVP]" wrote:

> Not sure I understand. Are you needing something other then dot-sourcing
> (i.e. . .\script.ps1) ? tia
>
> --
> William Stacey [C# MVP]
> PCR concurrency library: www.codeplex.com/pcr
> PSH Scripts Project www.codeplex.com/psobject
>
>
> "Adam Geras" <AdamGeras@discussions.microsoft.com> wrote in message
> news:F2F6D024-5721-4A89-BB72-A1A301A3C548@microsoft.com...
> | Hi,
> |
> | I'm seeking suggestions on the best way to #include script files. There
> are
> | many possible ways of doing this that I know about, but what do you think
> is
> | best?
> |
> | I'm leaning towards creating an environment variable as part of an
> | installation script and then using that value to build an absolute path
> name
> | that I can invoke.
> |
> | Please point me to other discussions on this topic if this has come up
> | before ..
> |
> | Thanks in advance,
> | Adam
> | http://www.codeplex.com/psexpect PowerShell Scripts for Testing
> | http://testfirst.live.spaces.com PowerShell for Testers
>
>
>

Hi William,

> Not sure I understand. Are you needing something other then dot-sourcing

The "problem" with dot-sourcing is that it needs an absolute path. And
Unfortunately we can't use paths relative to the executing or
dot-sourcing scripts folder.

Let's say we have a script Start-Me.ps1. This script needs a bunch of
other scripts lying in the same folder. So how should/could we
dot-source these scripts without hardcoding the full path? If we simply
dot-source them using .\Scriptname.ps1 then the Start-Me.ps1 script does
no longer work if the working directory doesn't point to the folder of
the Start-Me.ps1 script.

e.g. We have a folder c:\My Scripts. Inside this folder are the scripts
script1.ps1 to script9.ps1 and Start-Me.ps1. If Start-Me.ps1 is
implemented like this:

#Start-Me.ps1
.. \script1.ps1
.. \script2.ps1
#etc.

With this you have to 'cd' to the c:\My Scripts before running
Start-Me.ps1, otherwise the dot-sourced files can not be found.

I guess that's what Adam is talking about.

cu


Max

another alternative would be to create a foldder for these scripts and add
that folder to your PATH. you could then call the script from anywhere on
your system
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Adam Geras" wrote:

> No, that works fine, but I don't want to use the relative path name. I want
> this script that is to be 'installed' in one place, and then include it from
> several other scripts in (variable) locations.
>
> "William Stacey [C# MVP]" wrote:
>
> > Not sure I understand. Are you needing something other then dot-sourcing
> > (i.e. . .\script.ps1) ? tia
> >
> > --
> > William Stacey [C# MVP]
> > PCR concurrency library: www.codeplex.com/pcr
> > PSH Scripts Project www.codeplex.com/psobject
> >
> >
> > "Adam Geras" <AdamGeras@discussions.microsoft.com> wrote in message
> > news:F2F6D024-5721-4A89-BB72-A1A301A3C548@microsoft.com...
> > | Hi,
> > |
> > | I'm seeking suggestions on the best way to #include script files. There
> > are
> > | many possible ways of doing this that I know about, but what do you think
> > is
> > | best?
> > |
> > | I'm leaning towards creating an environment variable as part of an
> > | installation script and then using that value to build an absolute path
> > name
> > | that I can invoke.
> > |
> > | Please point me to other discussions on this topic if this has come up
> > | before ..
> > |
> > | Thanks in advance,
> > | Adam
> > | http://www.codeplex.com/psexpect PowerShell Scripts for Testing
> > | http://testfirst.live.spaces.com PowerShell for Testers
> >
> >
> >

yes, and worded much more eloquently - thank you. I have solutions in mind -
but I would like to know what the community thinks might be best.

"Maximilian Hänel" wrote:

> Hi William,
>
> > Not sure I understand. Are you needing something other then dot-sourcing
>
> The "problem" with dot-sourcing is that it needs an absolute path. And
> Unfortunately we can't use paths relative to the executing or
> dot-sourcing scripts folder.
>
> Let's say we have a script Start-Me.ps1. This script needs a bunch of
> other scripts lying in the same folder. So how should/could we
> dot-source these scripts without hardcoding the full path? If we simply
> dot-source them using .\Scriptname.ps1 then the Start-Me.ps1 script does
> no longer work if the working directory doesn't point to the folder of
> the Start-Me.ps1 script.
>
> e.g. We have a folder c:\My Scripts. Inside this folder are the scripts
> script1.ps1 to script9.ps1 and Start-Me.ps1. If Start-Me.ps1 is
> implemented like this:
>
> #Start-Me.ps1
> .. \script1.ps1
> .. \script2.ps1
> #etc.
>
> With this you have to 'cd' to the c:\My Scripts before running
> Start-Me.ps1, otherwise the dot-sourced files can not be found.
>
> I guess that's what Adam is talking about.
>
> cu
>
>
> Max
>
>

Clean and simple. I like that approach too.

"RichS" wrote:

> another alternative would be to create a foldder for these scripts and add
> that folder to your PATH. you could then call the script from anywhere on
> your system
> --
> Richard Siddaway
> Please note that all scripts are supplied "as is" and with no warranty
> Blog: http://richardsiddaway.spaces.live.com/
> PowerShell User Group: http://www.get-psuguk.org.uk
>
>
> "Adam Geras" wrote:
>
> > No, that works fine, but I don't want to use the relative path name. I want
> > this script that is to be 'installed' in one place, and then include it from
> > several other scripts in (variable) locations.
> >
> > "William Stacey [C# MVP]" wrote:
> >
> > > Not sure I understand. Are you needing something other then dot-sourcing
> > > (i.e. . .\script.ps1) ? tia
> > >
> > > --
> > > William Stacey [C# MVP]
> > > PCR concurrency library: www.codeplex.com/pcr
> > > PSH Scripts Project www.codeplex.com/psobject
> > >
> > >
> > > "Adam Geras" <AdamGeras@discussions.microsoft.com> wrote in message
> > > news:F2F6D024-5721-4A89-BB72-A1A301A3C548@microsoft.com...
> > > | Hi,
> > > |
> > > | I'm seeking suggestions on the best way to #include script files. There
> > > are
> > > | many possible ways of doing this that I know about, but what do you think
> > > is
> > > | best?
> > > |
> > > | I'm leaning towards creating an environment variable as part of an
> > > | installation script and then using that value to build an absolute path
> > > name
> > > | that I can invoke.
> > > |
> > > | Please point me to other discussions on this topic if this has come up
> > > | before ..
> > > |
> > > | Thanks in advance,
> > > | Adam
> > > | http://www.codeplex.com/psexpect PowerShell Scripts for Testing
> > > | http://testfirst.live.spaces.com PowerShell for Testers
> > >
> > >
> > >

I probably missing something basic here, but what about a var?

$myscripts = $home\myscripts
.. $myscripts\script1.ps1
.. $myscripts\script2.ps1

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


"Maximilian Hänel" <ngSpam@smjh.de> wrote in message
news:evso4wWSHHA.996@TK2MSFTNGP02.phx.gbl...
| Hi William,
|
| > Not sure I understand. Are you needing something other then dot-sourcing
|
| The "problem" with dot-sourcing is that it needs an absolute path. And
| Unfortunately we can't use paths relative to the executing or
| dot-sourcing scripts folder.
|
| Let's say we have a script Start-Me.ps1. This script needs a bunch of
| other scripts lying in the same folder. So how should/could we
| dot-source these scripts without hardcoding the full path? If we simply
| dot-source them using .\Scriptname.ps1 then the Start-Me.ps1 script does
| no longer work if the working directory doesn't point to the folder of
| the Start-Me.ps1 script.
|
| e.g. We have a folder c:\My Scripts. Inside this folder are the scripts
| script1.ps1 to script9.ps1 and Start-Me.ps1. If Start-Me.ps1 is
| implemented like this:
|
| #Start-Me.ps1
| . \script1.ps1
| . \script2.ps1
| #etc.
|
| With this you have to 'cd' to the c:\My Scripts before running
| Start-Me.ps1, otherwise the dot-sourced files can not be found.
|
| I guess that's what Adam is talking about.
|
| cu
|
|
| Max
|

Hi RichS,

> another alternative would be to create a foldder for these scripts and add
> that folder to your PATH. you could then call the script from anywhere on
> your system

That's right but it's not always a good solution because then you are
forced to include the script path in the PATH variable. There's no other
choice then.

Currently I force the user to 'cd' to the script folder. The script
dot-sourcing other scripts are "guarded" with Convert-Path like so:

#
[void](Convert-Path .\MyLibrary.ps1 -ea Stop)
.. .\MyLibrary.ps1

So the caller get's at least a little hint.
But actually I don't like it very much :-(

cu

Max

Hi William

> I probably missing something basic here, but what about a var?

Using a variable with a hard-coded path is IMHO a bad thing because one
has to modify all the scripts with dot-sourced libraries if the script
is on a different path on a different machine. It only saves a little
typing - nothing else :-(

As for me I prefer scripts to be independend of the "installation"
directory. I don't like it if I have to edit my scripts so I can run
them on a different machine. And btw it makes script versioning a
nightmare :-(

I'm still looking for a better solution...

cu

Max