Vista - Writing variables to memory versus tmp files

Instead of having a Powershell window open all the time, I might have PSH
scripts that run at various intervals. I may want the current script to get
variables defined in a previous run.

One way would be to have the script write to a tmp file, and have the next
run pull in any relevant data from that file to use.

I hate having to write temp files...

Perhaps PSH can write a host-based variable, and have that available for the
next run. Even something stored to RAM somehow would be kind of OK
(realizing that I'd lose that on a reboot).

Comments?

Marco

Have it both ways, and write temp files to a ram drive?

"Marco Shaw" wrote:

> Instead of having a Powershell window open all the time, I might have PSH
> scripts that run at various intervals. I may want the current script to get
> variables defined in a previous run.
>
> One way would be to have the script write to a tmp file, and have the next
> run pull in any relevant data from that file to use.
>
> I hate having to write temp files...
>
> Perhaps PSH can write a host-based variable, and have that available for the
> next run. Even something stored to RAM somehow would be kind of OK
> (realizing that I'd lose that on a reboot).
>
> Comments?
>
> Marco
>
>
>

Marco,

I would suggest saving the variables to the registry if you need to save
state. You can access the registry the same way you access a file on a hard
drive. See the Getting started manual that ships with the Powershell
documentation for examples.

-Daivd

"Marco Shaw" wrote:

> Instead of having a Powershell window open all the time, I might have PSH
> scripts that run at various intervals. I may want the current script to get
> variables defined in a previous run.
>
> One way would be to have the script write to a tmp file, and have the next
> run pull in any relevant data from that file to use.
>
> I hate having to write temp files...
>
> Perhaps PSH can write a host-based variable, and have that available for the
> next run. Even something stored to RAM somehow would be kind of OK
> (realizing that I'd lose that on a reboot).
>
> Comments?
>
> Marco
>
>
>

> Have it both ways, and write temp files to a ram drive?

A "ram drive"?

> I would suggest saving the variables to the registry if you need to save
> state. You can access the registry the same way you access a file on a
> hard
> drive. See the Getting started manual that ships with the Powershell
> documentation for examples.

Interesting idea... My data could be quite large though...

Marco

Basically an emulated logical disk. It only exists in memory, but the looks
like a physical disk to the OS. I believe ramdisk.sys is the device drive
you use to create one.

"Marco Shaw" wrote:

> > Have it both ways, and write temp files to a ram drive?
>
> A "ram drive"?
>
>
>

If its large then tmp file would probably be best. Does your process need to
be restartable at current position after a reboot? If so the persisting the
data to disk in some format would be safest
--
Richard Siddaway

Please note that all scripts are supplied "as is" and with no warranty


"Marco Shaw" wrote:

> > I would suggest saving the variables to the registry if you need to save
> > state. You can access the registry the same way you access a file on a
> > hard
> > drive. See the Getting started manual that ships with the Powershell
> > documentation for examples.
>
> Interesting idea... My data could be quite large though...
>
> Marco
>
>
>

I think a temporary file is ultimately the correct backing store for
temporary data like this. When you create them properly (i.e.:
[System.IO.Path]::GetTempFileName()), Windows has lots of mechanisms to help
keep your system clean.

It sounds like you hate /managing/ temp files. Why not write a few functions
that abstract that from you? It sounds like you'd want:

Set-PersistentVariable foo $fooData
$fooData = Get-PersistentVariable foo

You could have your prompt function check for and clean up old unused
variables every 10th prompt or something.

For simple data types, the Import-CliXml and Export-CliXml cmdlets should be
all that you need for persistence. If you think you'll be dealing with
really complex data, then you've got a bit more work cut out for you.
Serializing objects to disk is a bit tricky, since you need to intimately
know the details of what is important to persist.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Marco Shaw" <marco@Znbnet.nb.ca> wrote in message
news:eIt1bktGHHA.816@TK2MSFTNGP06.phx.gbl...
>> I would suggest saving the variables to the registry if you need to save
>> state. You can access the registry the same way you access a file on a
>> hard
>> drive. See the Getting started manual that ships with the Powershell
>> documentation for examples.
>
> Interesting idea... My data could be quite large though...
>
> Marco
>

"Lee Holmes [MSFT]" <lee.holmes@online.microsoft.com> wrote in message
news:%23AK2UnuGHHA.3540@TK2MSFTNGP02.phx.gbl...
>I think a temporary file is ultimately the correct backing store for
>temporary data like this. When you create them properly (i.e.:
>[System.IO.Path]::GetTempFileName()), Windows has lots of mechanisms to
>help keep your system clean.

One limitation with the GetTempFileName() option though is that you still
need to keep the temp file name somewhere for your next sessions.

Depending on your actual requirement, you may want to save your temp file
names in one single location, either in a text file or in the registry -
having them in the registry might help clean them up individually, whereas
storing them in a file would allow for (relatively) easy transfer to another
computer along with the temp files themselves if cross-system sharing is
required in addition to post-reboot persistence.

Jacques

Marco Shaw wrote:
> Instead of having a Powershell window open all the time, I might have PSH
> scripts that run at various intervals. I may want the current script to get
> variables defined in a previous run.
>
> One way would be to have the script write to a tmp file, and have the next
> run pull in any relevant data from that file to use.
>
> I hate having to write temp files...

Instead of saving them to "temp files", save them to non-temp files. I
mean, a file in a well-known location that's used for tracking this
information.