I can no longer use / at the windows xp command prompt, and it seems to have started after a botched cygwin installation, e.g. cd /windows won't work, but used to.
Can anyone think of how this might have happened?
OOPS! It doesn't normally work in XP, though I had read that it does in Vista. I simplified my problem and it was wrong. The real problem is:
I was using the cwrsync binaries (meant for cygwin use) that can be used at the command prompt in a way such as:
ssh -i /keydir/keyfile user#server
but after doing something (seems like it was installing cygwin), and even after reinstalling the cwrsync files, I can now only do:
ssh -i \keydir\keyfile user#server, i.e. I have to use the windows convention when referring to local files.
I posted this on the cwrsync forum, but it's not very active, so I was hoping someone might recognize what's going on here, I should maybe try the cygwin forum too.
Actually, since DOS 2.0, the kernel and file APIs have always supported forward slash, and many command line calls. See: http://blogs.msdn.com/larryosterman/archive/2005/06/24/432386.aspx.
I used to go to great pains to detect the OS and use a PATH_SEPARATOR type constant in PHP, when I discovered this by accident (it's use is now considered deprecated, in lieu of a simple "/").
Cheers.
You imagined it - it never worked.
If you happen to be in C:\ and type
C:\>cd /windows
it will take you to C:\WINDOWS\ but that's only because /windows is not a valid option to cd, so it tries ignoring the /.
Forward slash is a path separator in UNIX and cygwin, but Windows uses it for commandline options, eg. dir /w.
Related
I am working in Windows 8.1.
I need to install a driver file (.inf file) from command line. Which command do I need to use?
I know I have many other method for installing a .inf file, but I must install this from command line.
Please help me
Thanks in advance...
Granger's comment works in Windows 7 too. According to MS, PnPUtil (PnPUtil.exe) is included in every version of Windows, starting with Windows Vista.
It is useful for device drivers that do not have default install (right-click "Install" does not work for them).
pnputil -i -a <driverinf>
The default way for device drivers is:
pnputil -i -a <driverinf>
Legacy Drivers can´t be installed with pnputil and have to use LaunchINFSectionEx-Call
I tested the following and it works with several drivers from Windows 2000 up to Windows 10, 2012R2, 2016, 2019.
rundll32.exe advpack.dll,LaunchINFSectionEx ykmd.inf,Yubico64_Install.NT,,4,N
Pay attention to use the correct section
The correct section of the inf-File must be used, when there is no [DefaultInstall]-Section. This lacks in most answers. Look it up in your drivers inf-File and use the correct section (in my example "Yubico64_Install.NT"). Using the wrong section wont prompt an error. Im my example I use Quiet mode, no UI (4) and Never reboot (N) to install the driver automated via GPO. All options are documented in detail here:
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768006(v%3Dvs.85)
There are many variants ... and many complications with newer versions of Windows.
But for starters, try something like this:
rundll32.exe advpack.dll,LaunchINFSectionEx myinf.inf,,c:\temp\mydata.cab,36
http://www.msfn.org/board/topic/104891-how-can-i-install-a-inf-file-from-the-command-line/
http://msdn.microsoft.com/en-us/library/aa768006%28v=vs.85%29.aspx
Programmatic driver install via .inf causing reboot
Note: beware older links that suggest "setupapi" instead of "advpack". You definitely want advpack.dll.
I have downloaded strawberry PERL and writing one application with CGI Perl Apache on Winxp sp3).
One of the libraries (written by someone else) which I using uses XML::LibXML. When i load the page it gives Internal Server Error. From Apache error log i can see this error:
Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 190.
C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll exists with all permissions.
Also this library works properly on Linux. My application also works fine if I remove all code that needs LibXML.
Can anyone tell me when can be possible issue here.
If you peek into the source for DynaLoader you'll find
Many dynamic extension loading problems will appear to come from
this section of code: XYZ failed at line 123 of DynaLoader.pm.
Often these errors are actually occurring in the initialisation
C code of the extension XS file. Perl reports the error as being
in this perl code simply because this was the last perl code
it executed.
You should have also gotten (but may not have noticed) the following dialog, which provides a more accurate error message:
The problem isn't that perl can't find LibXML.dll; it's that LibXML.dll can't find the real libxml. (The former is just a wrapper that provides Perl bindings for the latter.) To fix that you need to ensure that Strawberry Perl's c\bin folder is in your PATH. In your case, that would be C:\strawberry\c\bin.
You might have to check the environment variable settings in the windows,
make sure that the installation path of the module is present in the PATH variable.
The reason it works in linux is that make files usually set the environment variables for you in linux in windows it may not have set properly.
For eg;
go to Control Panel\System and Security\System click change settings then advanced tab in user variable section see if there is a variable called perl5lib.
if not create an new perl5lib variable and add the path of your library ( usuall C:\Perl\site\lib but may be different in your case)
I had the same issue after installing Strawberry perl. It was working fine when I run the script from server, but not remotely from a automation tool. The issue was because of the Environment variables not updated when we run it remotely. So I did server reboot, which resolved the issue.
I encountered the same problem recently, in my case it was not related to PATH variable (it was already correct). The thing is I was executing my script from Git Bash console and as it turned out git-bash perl was being used instead of Strawberry (see git-bash perl should not be first in path). Switching to standard Windows CMD terminal helped.
I need to run 2 versions of perl on Windows 7.
The first one is bundled with VMware vCLI, it is Active State Perl 5.8.8.
The one I need for script dev is Stawberry 5.12.4 (something like that).
When I type perl -v It calls the AS perl which does not seem to support things like named captures and other things I took for granted in perl.
Both perls are installed I just don't know how to call Stawberry instead of AS perl.
Any idea?
Your specific problem can be addressed by editing the PATH environment variable, as noted by David Heffernan.
System control panel
> Advanced system settings
> Environment variables
> Path
> Edit...
More broadly, here's the general approach I am currently using to manage multiple versions of Perl, Python, etc. on Windows 7. I would appreciate tips for better ways to do this.
I create a Perl installation area like this:
C:\usr\perls\
5.10\
5.12\
etc.
current # Symbolic link.
In that same area I create a symbolic link (current) referring to the version I want as my default, and I make sure that all Perl references in my PATH environment variable use current rather than specific version numbers.
# Open cmd window as an administrator.
cd C:\usr\perls
mklink /D current 5.12
Under that approach, I can quickly modify my system's default Perl by changing one symbolic link rather than making multiple edits to PATH, which is a more tedious.
In addition, I add a directory to my PATH containing batch scripts to invoke specific Perls.
C:\usr\bin
perl5.10.bat
perl5.12.bat
etc.
Those scripts look like this example:
# C:\usr\perls\5.12\perl\bin\perl.exe %*
I'd do this by changing the PATH environment variable. Make it point to the 5.12 version and you may find that the VMware code continues working because it knows where to find it its Perl. If not, make a .bat file that sets PATH to refer to the 5.12 installation and use that to launch into a cmd window from which calls to perl invoke 5.12.
I am wanting to create an install script in the fashion of npm's (curl http://example.com/install.sh | sh) but it leaves me asking the question: can I just write the script in perl? As far as I know, perl is installed by default on at least ubuntu, RHEL & OS X - so I'm wondering in the year 2011, can I not write shell and still be generic enough for everyone? Is there a third and better option?
This would be targeting a user's development box, not staging or production.
What I want to do specifically is use this install script to bootstrap a development environment easily without the overhead of creating and maintaining packages. The script would have 4 steps:
check and make sure git is installed
use git to clone a repo to cwd
pull down and save a perl control script to /usr/bin, make it executable
add some environment variables (related post: linux cross-distro environment variable modification via script?)
That's it. My thinking is this is simple and generic enough to use a bootstrap script rather than a package. And my target audience is a user's unix or linux local development system.
The best option is to simply use the existing, well-oiled and -used (development) toolchain for the language the target app is written in. Not doing so frivolously discards the network effects gained from the ecologies that have grown around them.
C: GNU autotools
Haskell: Cabal
Perl: EU::MM, M::B, M::I
etc. etc.
Installing from the Web should be reserved for conveniently bootstrapping a user's system into the development environment.
Do tell more details about your software to get less general advice.
Edit: response to your addendum.
I dissuade you from a Web installer. This isn't bootstrapping an installation tool, this is plain installation of software and it should be done with with e.g. a Module::Build subclass.
I think perl is ubiquitous enough for you to write your installer in it. Shell is a lot more awkward anyway.
You might want to consider actually packaging your application as a deb or rpm or even using makeself rather than providing a raw script.
Here's a list of the various distributions of perl:
https://www.socialtext.net/perl5/distributions
Even if perl doesn't ship on every little obscure distro it's just an apt-get (or whatever) away. You might run into problems due to the various versions of perl installed however.
Use something like:
perl -E "$( wget -q -O - http://host/intall.pl )"
Also you can use
`cmd`
instead of
$(cmd)
but anyway, double-quote your choice.
I'm having trouble installing Template module with Strawberry Perl.
cpan Template
yields the following:
Writing Makefile for AppConfig
C:strawberryperlbinperl.exe: not found
dmake.EXE: Error code 255, while making 'blib\lib\.exists'`
I haven't been able to understand either
how to affect the path so dmake will work correctly
why the path (which is correct) does not have any \ in it.
If you've been using MKS, you not only need to be sure you've removed it from your PATH, but you also need to ensure you don't have SHELL set to point to the MKS sh.exe.
I removed it from my PATH, and continued to struggle with this for a couple of more days until I realized dmake was invoking the wrong shell.
Hope this helps someone else down the road.
The answer was I needed to uninstall (or at least remove from my path) the MKSTookit (basically a unix shell environment for Windows like Cygwin.) Not exactly sure why this fixed the problem - but it has cleared things up and I am able to install via CPAN.
Thanks for everybody's answers and comments.
You've probably been bit by escaping. Somewhere something is configured with the path C:\strawberryperl\bin\perl.exe, but those slashes need to be escaped to:
C:\\strawberryperl\\bin\\perl.exe
Not knowing more about how you installed your perl, I can't tell you where this bad config value is likely to be found.