Modules don't work very well on Windows as there is no support for the cmd
shell in modules (modules only supports bash, ksh, zsh, sh, csh, tcsh, and
perl). The users would have to run their code from an sh/bash shell (you can
get natively compiled versions of sh and tcl/tk).
If you use shortcuts to start the programs, you might as well use .bat/.cmd
files to set up the environment as you start them (as the environment changes
made by the .bat file won't be reflected in explorer, and there is no need to
be able to undo the changes). Windows environment inheritance works very
much like any other OS (the environment is only inherited by Child processes)
- with the caveat that explorer might be told reinitialize its environment
from the registry after an installation, or if you use the gui to set the
environment settings. Also note that Windows XP, Vista and 7 follow an
additional registry key for User Environment initialization:
[HKEY_CURRENT_USER\Volatile Environment]
Which NORMALLY clears itself when the user logs out (Windows uses this key
itself, so be careful about overwriting existing values). It is interpreted
last in the chain, and PATH is interpreted in the same weird way as it is in the:
[HKEY_CURRENT_USER\Environment]
Key - that is: PATH is appended to the existing PATH environment Variable.
I myself just use .bat (or .cmd) files to set up the environment before
starting up shared programs from a server. From my experience, Microsoft
Software overuses long filenames, but is very dependant on the generated
short file names (this issue tends to bleed into any project compiled with
Microsoft Compilers). So if you are going to run most Microsoft programs
from a share, that share will have to come from a real windows machine (not
samba, nor any other CIFS server, unless it generates AND SAVES short file
names exactly the same way windows does). Also, Microsoft Software
installations are .dll/.ocx happy and want to have all those .dll/.ocx files
registered on the machine before they work. Windows machines get very flaky
if registered .dll/.ocx files come from a network share (this is also why it
probably is nearly impossible to have multiple versions of Visual Studio
installed on a machine). Even worse, Microsoft software is self "fixing"
(AKA self breaking - it basically tries to reinstall itself if it THINKS
something is not quite right, these programs shortcuts are actually links
through the Windows installer). I don't even try to get Microsoft Programs
to run from a share (I do get quit a bit of other stuff to do so, including
Cygwin, Openoffice, Firefox, Several very large engineering programs, and
others). I have the most luck with programs that fully support Windows and
Linux/Unix and operate essentially the same on both platforms (the majority
of the configuration in files, little to no dependance on the registry).
Mark Lakata wrote:
> I have used modules with Visual Studio and other windows command line tools,
> in cygwin. I wrote the TCL port of modules just for cygwin, because I
> couldn't compile the C version.
>
> Running VS on a shared drive is an open question. I had VS installed locally.
> I do not know how the license keys work.
>
> I have dealt with getting cygwin paths (/cygpath/T) and DOS paths (T:) to get
> along with each other.
>
> I have sample module files on my retired hard drive, so if you are
> interested, I can excavate them tonight.
>
> I have not done any registry changes with modules.
>
> You can't use modules to deal with the Windows Shell. This is purely from the
> cygwin command line.
>
> -Mark
>
>
> On 9/21/2011 2:40 PM, Tom Lynch wrote:
>>
>> Hi,
>>
>> We have several Windows boxes which we use Cygwin on. We were wondering if
>> it's possible
>>
>> to load all the tools on a shared mapped drive (T:) and use Cygwin and
>> Modules to dynamically
>>
>> switch between tools (i.e. VS2005 to VS2008 or VS2010, etc...). Has anyone
>> tried this before? What
>>
>> problems/issues did you run into (Registry)? Is this really out of the
>> scope for Modules?
>>
>> Thanks for any input.
>>
>> Tom
>>
>> *Tom Lynch*
>> Automation/Systems Admin. Engineer | P&S Engineering Shared Services
>>
>> *Avid*
>> 75 Network Drive
>> Burlington, MA 01803
>> United States
>> tom.lynch@... <mailto:tom.lynch@...>
>>
>> t 978-640-5059
>>
>> *We're Avid.*Learn more at http://www.avid.com <http://www.avid.com/>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Modules-interest@...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Modules-interest@...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
--
---------------------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s). The content of this message has
not been reviewed nor approved by any entity whatsoever.
---------------------------------------------------------------------
Paul Markfort Info: http://www.umn.edu/~paulfm
---------------------------------------------------------------------
|