Strawberry Perl: forgets environment variables? - windows

I've installed a number of modules into my Strawberry Perl running on Windows XP, such as:
Regexp::Common
URI::Find::Schemeless
These libraries work fine in my perl code the first time directly after installing each module.
The problem is that every subsequent day I run my scripts they fail with the error:
Can't locate Regexp/Common.pm in #INC (#INC contains: C:/strawberry/perl/lib C:/ strawberry/perl/site/lib C:\strawberry\perl\vendor\lib .)
I have put all the appropriate paths into environment variables into Windows: PERL5LIB and others such as lib that were suggested on various other answers on stackoverflow and other wesites dealing with module installations.
The scripts continue to fail unless I perform the following workaround that I figured out:
Open the "edit the environment variables" window in Windows. ("My Computer" -> "Properties" -> "Advanced" tab -> "Environment Variables")
Without adding or changing anything, click OK.
Re-open any perl consoles that were already open or open a new perl window.
Now the libraries are all found without issues.
Does anyone have an idea why this might be happening? I suspect it may be something specifically related to Windows/cmd or even my company's windows environment setup?
Any suggestions would be appreciated because it is an extremely annoying problem!

Windows does not clear the environment variables daily by default, therefore it's likely something in your corporate settings resetting the environment variables.
If this is the case, you have a few options:
Get the network admins to modify the script so that it doesn't reset them (or includes the PERL5LIB directories you want to specify).
Write another daily task, running after their daily task, which re-adds the variables on your local machine.
Wrap your perl scripts with a Windows batch file, or run them with perl -I to specify the library at run time.
Run your perl scripts from Cygwin bash or mingw bash, which won't use your computer's global environment variables.

Related

cl.exe is not being found in path variable but works after having been added programatically [duplicate]

Sometimes when I change my environment variables in Windows, and then use software the depends on those variables, they are not properly updated.
And good example is to change a variable, then open up Windows Command Line and echo the variable and see that it hasn't been changed, even though you properly changed it in the Environment Variables window.
Another example I'm dealing with right now:
I've been using Python 2.4.x for a while for a project, which uses the env var PYTHONPATH who's value has been:
C:\Python24;C:\Python24\lib
Today I installed Python 2.5.x for the project. I changed my PYTHONPATH to be:
C:\Python25;C:\Python25\lib
When I use Python 2.5 to run a script and do this:
import sys
print sys.path
It prints:
'C:\\PYTHON24', 'C:\\PYTHON24\\lib' (and some other Python 2.5 related default installation paths)
So clearly, the old PYTHONPATH environment variable changes aren't really sticking....
Does anyone know why this happens and how to fix it?
When you change an environment variable in the System Properties tab, the new value will propagate to the Windows Explorer, and any apps (such as cmd.exe) opened from the Windows Explorer (or the Run box, Start Menu, etc.) should see the new value.
However, if you're running a program such as an editor or python or some non-Microsoft program launcher, then change an environment variable, and then launch cmd.exe from that program (instead of Windows Explorer) you are likely to see the old value of the environment variable. The reason is that the running program ignored the notification from Windows saying that the environment has changed (not at all unusual), and since the launched process inherits the environment variables, the child process won't see the changes.
The workaround is to make sure you start your app from Windows Explorer or the Run box. Rebooting your machine will work also (if rebooting doesn't solve the problem, then something else is going on).

How can I execute a bash file (.sh) on PostgreSQL? On windows [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have bought and I use Windows 7 Ultimate, and I like to use it to develop applications. One of the down sides (as with every OS) is that I can not run Bash scripts. Is there a way to run Bash scripts on Windows by installing some software? It is ok if it does not work 100%, but as long as the most common functionality is available it should be great.
Install Cygwin, which includes Bash among many other GNU and Unix utilities (without whom its unlikely that bash will be very useful anyway).
Another option is MinGW's MSYS which includes bash and a smaller set of the more important utilities such as awk (you may also want to check the competing fork - Mingw-w64). Personally I would have preferred Cygwin because it includes such heavy lifting tools as Perl and Python which I find I cannot live without, while MSYS skimps on these and assumes you are going to install them yourself.
Updated:
If anyone is interested in this answer and is running MS-Windows 10, please note that MS-Windows 10 has a "Windows Subsystem For Linux" feature which - once enabled - allows you to install a user-mode image of Ubuntu and then run Bash on that. This provides 100% compatibility with Ubuntu for debugging and running Bash scripts, but this setup is completely standalone from Windows and you cannot use Bash scripts to interact with Windows features (such as processes and APIs) except for limited access to files through the DrvFS feature.
Best Option I could find is Git Windows Just install it and then right click on and click "Git Bash Here" this will open a bash window
This will open a bash window like this:
and the linux commands work...
I've tried 'sh' , 'vi' , 'ssh' , 'curl' ,etc... commands
If you're looking for something a little more native, you can use getGnuWin32 to install all of the Unix command line tools that have been ported. That plus winBash gives you most of a working Unix environment. Add console2 for a better terminal emulator and you almost can't tell you're on Windows!
Cygwin is a better toolkit overall, but I have found myself running into surprise problems because of the divide between it and Windows. None of these solutions are as good as a native Linux system though.
You may want to look into using virtualbox to create a linux VM with your distro of choice. Set it up to share a folder with the host os, and you can use a true linux development environment, and share with windows. Just watch out for those EOL markers, they get ya every time.
Best option? Windows 10. Native Bash support!
You can always install Cygwin to run a Unix shell under Windows. I used Cygwin extensively with Window XP.
After installing git-extentions (http://gitextensions.github.io/) you can run .sh file from the command prompt. (No ./script.sh required, just run it like a bat/cmd file)
Or you can run them in a "full" bash environment by using the MinGW Git bash shell.
I am not a great fan of Cygwin (yes I am sure it's really powerful), so running bash scripts on windows without having to install it perfect for me.
In order to run natively, you will likely need to use Cygwin (which I cannot live without when using Windows). So right off the bat, +1 for Cygwin. Anything else would be uncivilized.
HOWEVER, that being said, I have recently begun using a combination of utilities to easily PORT Bash scripts to Windows so that my anti-Linux coworkers can easily run complex tasks that are better handled by GNU utilities.
I can usually port a Bash script to Batch in a very short time by opening the original script in one pane and writing a Batch file in the other pane. The tools that I use are as follows:
UnxUtils (http://sourceforge.net/projects/unxutils/)
Bat2Exe (http://bat2exe.net/)
I prefer UnxUtils to GnuWin32 because of the fact that [someone please correct me if I'm wrong] GnuWin utils normally have to be installed, whereas UnxUtils are standalone binaries that just work out-of-the-box.
However, the CoreUtils do not include some familiar *NIX utilities such as cURL, which is also available for Windows (curl.haxx.se/download.html).
I create a folder for the projects, and always SET PATH=. in the .bat file so that no other commands other than the basic CMD shell commands are referenced (as well as the particular UnxUtils required in the project folder for the Batch script to function as expected).
Then I copy the needed CoreUtils .exe files into the project folder and reference them in the .bat file such as ".\curl.exe -s google.com", etc.
The Bat2Exe program is where the magic happens. Once your Batch file is complete and has been tested successfully, launch Bat2Exe.exe, and specify the path to the project folder. Bat2Exe will then create a Windows binary containing all of the files in that specific folder, and will use the first .bat that it comes across to use as the main executable. You can even include a .ico file to use as the icon for the final .exe file that is generated.
I have tried a few of these type of programs, and many of the generated binaries get flagged as malware, but the Bat2Exe version that I referenced works perfectly and the generated .exe files scan completely clean.
The resulting executable can be run interactively by double-clicking, or run from the command line with parameters, etc., just like a regular Batch file, except you will be able to utilize the functionality of many of the tools that you will normally use in Bash.
I realize this is getting quite long, but if I may digress a bit, I have also written a Batch script that I call PortaBashy that my coworkers can launch from a network share that contains a portable Cygwin installation. It then sets the %PATH% variable to the normal *NIX format (/usr/bin:/usr/sbin:/bin:/sbin), etc. and can either launch into the Bash shell itself or launch the more-powerful and pretty MinTTY terminal emulator.
There are always numerous ways to accomplish what you are trying to set out to do; it's just a matter of combining the right tools for the job, and many times it boils down to personal preference.
There's one more theoretical possibility to do it: professional versions of Windows have built-in POSIX support, so bash could have been compiled for Windows natively.
Pity, but I still haven't found a compiled one myself...

Problems installing Python 27 on Windows 7 - cannot add Python to PYTHON PATH

I installed Python 2.7.3 on my Windows 7 computer using the binary, the first link. After installing it, IDLE works but nothing else recognizes Python. For example, typing python at the command prompt returns the message "'Python is not recognized as an internal or external command, operable program or bath file."
Following this post, I made sure that python 2.7 was in the PYTHONPATH environment variable. However, that didn't help.
What should I do?
PYTHONPATH system variable is used by Python itself to find directories with installed packages.
PATH system variable is used by OS (particularly Windows) to find executables which can open certain files like *.py scripts.
So, you need to add directory with python.exe (for example C:\Python27) to PATH system (or user) variable and not to PYTHONPATH. It can be done the same way as described in the link you've found in the same tool window.
For example on my machine PATH system variable is set to C:\Python27;C:\MinGW\bin;...
Like Vladimir commented, for setting up python in windows, you need to add the directory where your python.exe is located (for example C:\Python27) to PATH
You can confirm if python is in your environment variables by looking at the output of echo %path%
Keep in mind that after editing the PATH variable using the control panel, you have to open a new terminal, as the setting will NOT be updated in existing terminals.
Another possibility is that you added the wrong path to the PATH variable. Verify it.
The bottom line is, if the directory of your python.exe is really in PATH, then running python will really work.
Here are your steps:
Right-click Computer and select Properties.
In the dialog box, select Advanced System Settings.
In the next dialog, select Environment Variables. In the User Variables section, edit the PATH statement to include this:
C:\Python27;C:\Python27\Lib\site-packages\;C:\Python27\Scripts\;
Now, you can open a command prompt (Start Menu|Accessories or Start Menu|Run|cmd) and type:
C:\> python
That will load the Python interpreter!
You can install for single user rather than choosing the option of "Install for all users". I was facing the same issue, but when I tried installing just for myself, I was able to install successfully.

Is there a way to run Bash scripts on Windows? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have bought and I use Windows 7 Ultimate, and I like to use it to develop applications. One of the down sides (as with every OS) is that I can not run Bash scripts. Is there a way to run Bash scripts on Windows by installing some software? It is ok if it does not work 100%, but as long as the most common functionality is available it should be great.
Install Cygwin, which includes Bash among many other GNU and Unix utilities (without whom its unlikely that bash will be very useful anyway).
Another option is MinGW's MSYS which includes bash and a smaller set of the more important utilities such as awk (you may also want to check the competing fork - Mingw-w64). Personally I would have preferred Cygwin because it includes such heavy lifting tools as Perl and Python which I find I cannot live without, while MSYS skimps on these and assumes you are going to install them yourself.
Updated:
If anyone is interested in this answer and is running MS-Windows 10, please note that MS-Windows 10 has a "Windows Subsystem For Linux" feature which - once enabled - allows you to install a user-mode image of Ubuntu and then run Bash on that. This provides 100% compatibility with Ubuntu for debugging and running Bash scripts, but this setup is completely standalone from Windows and you cannot use Bash scripts to interact with Windows features (such as processes and APIs) except for limited access to files through the DrvFS feature.
Best Option I could find is Git Windows Just install it and then right click on and click "Git Bash Here" this will open a bash window
This will open a bash window like this:
and the linux commands work...
I've tried 'sh' , 'vi' , 'ssh' , 'curl' ,etc... commands
If you're looking for something a little more native, you can use getGnuWin32 to install all of the Unix command line tools that have been ported. That plus winBash gives you most of a working Unix environment. Add console2 for a better terminal emulator and you almost can't tell you're on Windows!
Cygwin is a better toolkit overall, but I have found myself running into surprise problems because of the divide between it and Windows. None of these solutions are as good as a native Linux system though.
You may want to look into using virtualbox to create a linux VM with your distro of choice. Set it up to share a folder with the host os, and you can use a true linux development environment, and share with windows. Just watch out for those EOL markers, they get ya every time.
Best option? Windows 10. Native Bash support!
You can always install Cygwin to run a Unix shell under Windows. I used Cygwin extensively with Window XP.
After installing git-extentions (http://gitextensions.github.io/) you can run .sh file from the command prompt. (No ./script.sh required, just run it like a bat/cmd file)
Or you can run them in a "full" bash environment by using the MinGW Git bash shell.
I am not a great fan of Cygwin (yes I am sure it's really powerful), so running bash scripts on windows without having to install it perfect for me.
In order to run natively, you will likely need to use Cygwin (which I cannot live without when using Windows). So right off the bat, +1 for Cygwin. Anything else would be uncivilized.
HOWEVER, that being said, I have recently begun using a combination of utilities to easily PORT Bash scripts to Windows so that my anti-Linux coworkers can easily run complex tasks that are better handled by GNU utilities.
I can usually port a Bash script to Batch in a very short time by opening the original script in one pane and writing a Batch file in the other pane. The tools that I use are as follows:
UnxUtils (http://sourceforge.net/projects/unxutils/)
Bat2Exe (http://bat2exe.net/)
I prefer UnxUtils to GnuWin32 because of the fact that [someone please correct me if I'm wrong] GnuWin utils normally have to be installed, whereas UnxUtils are standalone binaries that just work out-of-the-box.
However, the CoreUtils do not include some familiar *NIX utilities such as cURL, which is also available for Windows (curl.haxx.se/download.html).
I create a folder for the projects, and always SET PATH=. in the .bat file so that no other commands other than the basic CMD shell commands are referenced (as well as the particular UnxUtils required in the project folder for the Batch script to function as expected).
Then I copy the needed CoreUtils .exe files into the project folder and reference them in the .bat file such as ".\curl.exe -s google.com", etc.
The Bat2Exe program is where the magic happens. Once your Batch file is complete and has been tested successfully, launch Bat2Exe.exe, and specify the path to the project folder. Bat2Exe will then create a Windows binary containing all of the files in that specific folder, and will use the first .bat that it comes across to use as the main executable. You can even include a .ico file to use as the icon for the final .exe file that is generated.
I have tried a few of these type of programs, and many of the generated binaries get flagged as malware, but the Bat2Exe version that I referenced works perfectly and the generated .exe files scan completely clean.
The resulting executable can be run interactively by double-clicking, or run from the command line with parameters, etc., just like a regular Batch file, except you will be able to utilize the functionality of many of the tools that you will normally use in Bash.
I realize this is getting quite long, but if I may digress a bit, I have also written a Batch script that I call PortaBashy that my coworkers can launch from a network share that contains a portable Cygwin installation. It then sets the %PATH% variable to the normal *NIX format (/usr/bin:/usr/sbin:/bin:/sbin), etc. and can either launch into the Bash shell itself or launch the more-powerful and pretty MinTTY terminal emulator.
There are always numerous ways to accomplish what you are trying to set out to do; it's just a matter of combining the right tools for the job, and many times it boils down to personal preference.
There's one more theoretical possibility to do it: professional versions of Windows have built-in POSIX support, so bash could have been compiled for Windows natively.
Pity, but I still haven't found a compiled one myself...

How do we configure SSH using Perl in Windows?

Can anyone suggest a a very simple way to use Net::SSH::Perl in Windows without all those cygwin hacks and all.
Whenever I am trying to install the modules it's taking me to some other dependent modules and the process seemed never ending..
Thanks beforehand
Here is a post on how to do it I found.
I recently had a project that required a script to perform an SSH session to a Cisco device and make some configuration changes. My favourite scripting language is, of course, perl.
I had previously written scripts using the Net::Telnet module that would Telnet to a device, detect various device prompts and send commands to the device to change its configuration. So, I thought that this was going to be a fairly straightforward case of just finding a suitable, similar module that uses SSH instead of Telnet.
The other thing that I need to mention is that I am generally constrained to using Win32 platforms (i.e. Windows 200, 2003, XP) due to the fact that most client sites that I work on these days do not use Unix(or Linux) ..which is a real pity in my opinion, but I don't set the corporate policies of my clients.
An initial glance of the available perl modules revealed a number of modules which seemed to be just what I needed :
Net::Appliance::Session
Net::SSH::W32Perl
Net::SSH
So, I told my boss, 'Yep, no problem' and set about pulling together a script to SSH in to a remote device and send it some commands to change its configuration.
After a day or so of trying various modules, I thought : 'Hmmm, maybe this isn't going to be as easy as I'd thought!'
Each of the modules I'd looked at seemed to have an issue when it came to using it in a Windows environment. To summarise, here are the issues I found with each module :
* Net::Appliance::Session : has a dependency on IO::Pty, which won't ever run on Windows
* Net::SSH::W32Perl : ``getpwuid function is unimplemented'' message`` when building from scratch. Older ppd's found at http://www.soulcage.net/ppds.58 just don't seem to work....even when installed in to the Activestate perl distribution
* Net::SSH : Unix only
So, at this point, I was beginning to think that maybe this just wasn't going to work at all on Windows....
Then, I remembered seeing a posting on perl mongers where someone has mentioned that they had used perl in cygwin to run one of the Net::* modules.
So, although the thought of having to download and install cygwin didn't initially seem too appealing, I thought I'd give it a go as I had no where else to go.
Cygwin
Cygwin is...well, let me quote directly from the cygwin web site :
``Cygwin is a Linux-like environment for Windows. It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality. A collection of tools which provide Linux look and feel.
The Cygwin DLL currently works with all recent, commercially released x86 32 bit and 64 bit versions of Windows, with the exception of Windows CE.``
So, it allows you to run in a Linux-type environment...sounds far more promising for the various Net::* modules that I had been looking at.
Also, once the basic cygwin core is installed, it allows you to download and install a whole host of other goodies, including perl !
So, I set about installing cygwin by downloading the 'setup.exe' file from the cygwin home page and running it on my PC.
Cygwin provides a failrly intuitive GUI to let you select a mirror to download files from, and which packages you would like to download.
Here are the packages that I installed beyond just the basic core cygwin packages that are installed for you :
gcc-core
gnupg
make
ncftpget
openSSH
perl
perl-ExtUtils
wget
zip
You can install others (in addition) if you like, but these did the job for me.
Perl
Once I had cygwin installed (including the perl distribution that I included), I was all set to add in the modules that I wanted to try to use (e.g. Net::SSH::Appliance).
If you are familiar with perl on Unix systems, then you will probably be very familiar with the CPAN shell to add modules into your perl distribution. Under cygwin, the process is exactly the same.
If you are used to using the Activestate version of perl, you are probably used to using the Activestate PPM manager to add new modules to perl. Well, the bad news is that under cygwin, you don't have a PPM manager, and you have to use the CPAN shell, which is a little bit trickier to use if you aren't used to it. The good news however, is that you will have access to far more perl modules !
When you installed cygwin, it will have put an icon somewhere (either on your desktop, quicklauch bar or start menu) so that you can launch the cygwin shell (it looks something like this :
If you click the shell icon, you will get a nice cygwin shell open up where you can type in various commands. You can think of it as a Unix shell to all intents and purposes.
To load in the perl modules you'll need, you need to enter 'cpan' at the command prompt. This will allow you to load new modules in to your perl distribution.
Now, the first time you go in to the CPAN shell, it will aks you lots of rather awkward questions about where various utilities are and which mirror you would like to use. In the main, if you have installed the modules that I recommended for cygwin, you can accept the defaults. (The mirror you will have to figure out for yourself - it depends where in the world you are).
The only setting I would recommend you change from the default is the question about whether you should be 'asked or follow' for pre-requisite modules - I would go for 'follow' to save a lot of hassle.
Once you have your cpan shell open (you can tell, because you now have a 'cpan>' prompt), you need to enter the following commands to load in some perl modules that you will need :
install LWP (accept all defaults to any questions asked)
install Net::Appliance::Session
When you enter these commands, you will see lots of things flying up the screen as the modules are installed for you.
Running Scripts
Well, at this point, we have taken a rather whirlwind tour through getting cygwin and perl instaled on your platform, but you should now be in a position to run some perl scripts.
We installed the Net::Appliance::Session module in to your perl distribution, so that we can run perl scripts that will use it to give us either Telnet or SSH sessions to a target device.
As we are running under the cygwin environment, we can now use this module on a Windows platform - something we couldn't do by just installing Activestate perl, or even by compiling our own version of perl under Windows. So, now, we CAN run perl scripts that will allow us to perform SSH sessions to network devices that only support SSH.
You may be wondering : ``does that mean that I have to run my perl scripts from the cygwin shell every time I need to run them ?''. Well, the good news is that no, you don't..! As long as you call the cygwin perl executable to run your script, it will run fine from a DOS prompt (or system scheduler !). So, this would work fine :
c:\ c:\cygwin\bin\perl.exe myscript.pl
Anyhow, I guess that's enough to let you know how I cracked my particular issue. I hope to cover all of this in a little more detail in future aritcles, as well as providing more informatipon about how to use the incredibly useful Net::Appliance::Session module to create some useful scripts to control and configure your network devices.
http://perlwin32ssh.blogspot.com/2007/07/test_4418.html
For ActiveState Perl, probably you can try for Net::SSH2 module. I tried with couple of online examples and it worked for me.
You can go through following resources to install and run a sample example using Net::SSH2.
Use this repository to install Net::SSH2
http://theoryx5.uwinnipeg.ca/ppms/
couple of examples:
http://www.perlmonks.org/?node_id=569657
Hope this will work for you. I tried it and it worked for me.
The answer about using Perl from within Cygwin then calling it from the Windows command line is the correct answer. THANKS VERY MUCH FOR YOUR EFFORT!
However, this method to call a PERL instance running in Cygwin from the Windows Command Line is not always optimum:
c:\cygwin\bin\perl.exe myscript.pl
That technique will work with some Perl scripts but not all. It was giving me heck trying to use NET:SSH:EXPECT and the login() method. It would abort with strange errors.
A better way to call your Perl instance running in Cygwin from the Windows command prompt is this:
c:\cygwin\bin\bash --login -c 'perl myscript.pl'
This seems to execute the Perl script fully within the Cygwin environment and even complicated Perl scripts or those with many dependencies or not capable of dealing with MSDOS style path names, will still run. You can still return the output of the Perl script back to the Windows command window, for instance using print() from within your Perl script.

Resources