I have a Perl program that someone else created and I am calling on with CruiseControl. The program calls on Unix Commands using Cygwin. However, everytime that the Perl program calls on a Unix like command with a DOS like address, I get the well known error:
cygwin warning:
MS-DOS style path detected: E:\regression
Preferred POSIX equivalent is: /cygdrive/e/regression
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I have set both the User Variable AND System Variable CYGWIN to nodosfilewarning. This removes the error when I run the program from the command line, but the error still occurs in CruiseControl when called as an automated process from a batch file. I have called on both the batch file from the Desktop AND Command Line and ran as an administrator. Nothing changes.
Other Notes
For purposes of this problem, I don't have access to the Perl Program
I am trying to go back to Cygwin 1.5.*, but since I am using Server 2008, I am encountering compatibility issues
This is occurring on one of the distributed servers, not the main server running the Webdashboard.
I have read somewhere that this issue may stem from a different user calling on CruiseControl, but the issue should have been solved by setting this as an ENV System variable
Is it possible to modify the registery to set the ENV variables?
Thank you in advance
The way I do it is like this
printf 'export CYGWIN=nodosfilewarning' >> ~/.bash_profile
If CruiseControl is connecting to the server via ssh, reinstall sshd and explicitly include nodosfilewarning when prompted for the CYGWIN environment variable during the install.
Re-installing with modified environment will work but if you don't want to or cannot re-install, an alternative is to change the registry instead of re-installing the service.
See: CYGWIN windows cygrunsrv sshd server and MS-DOS style path detected
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I want to disable cygwin temporarily without uninstalling it (e.g. for the duration of a batch script).
I was hoping there is a simple way, e.g. an environment variable like
$> SET cygwin=OFF
or an internal cygwin command like
$> cygset off
Right now I am using a quick and dirty solution that simply invalidates the cygwin directory in the Windows path with
SET PATH=%PATH:Cygwin=%
Of course this will also corrupt other pathes that have Cygwin in it.
I would like to customize the $PATH variables included in the Cygwin environment, how can I do this? One solution I know of is to add the following line to the end of the Cygwin.bat file:
PATH="/usr/local/bin:/usr/bin:/bin"
By default the shortcut starts bin/mintty.exe, how can I change that default behavior?
All Windows environment variables are included in your Cygwin environment automatically on startup. If you'd like to customize what they are, you can overwrite the whole $PATH variable using a line similar to what you already mentioned in your Cygwin.bat file:
PATH="colon:separated:list:of:all:paths"
Also if you'd like to change which terminal is used by Cygwin, one alternative is rxvt.
Another popular solution seems to be using PuttyCyg to putty directly into your Cygwin installation to get the benefits of the Putty terminal. See the effective-cygwin
GitHub page for setup instructions and more.
See this stackoverflow post for a full list of suggested alternatives to the default Cygwin terminal.
Not really sure where to go with this one. I have a PHP script that invokes a PERL script that connects to an Informix database. This setup works just fine when I run the script to the Windows cmd prompt, but when I attempt to run it through cron in cygwin it fails on
[Informix][Informix ODBC Driver]Unable to load translation shared library (DLL). (SQL-IM009)
I have tried adding the Informix bin directory (/cygdrive/c/Program\ Files\ (x86)/IBM/Informix/Client-SDK/bin) to the PATH variable in the crontab file but there were no changes. I also tried adding that same directory to the INFORMIXDIR variable in the crontab file, but then I got the following error message
[Informix][Informix ODBC Driver][Informix]Unspecified System Error = -23101. (SQL-HY000)
If I look that error in finderr.exe (supplied by the driver) I see that it means that it is Unable to load locale categories or my INFORMIXDIR is incorrect, but I am not sure how to set the CLIENT_LOCALE or DB_LOCALE.
Then I think I fixed this by using the correct directory separators and I dropped the bin subdirectory for the INFORMIXDIR variable in crontab, because I got the SQL-IM009 error again.
I am using the Windows PHP and PERL executables in cygwin, so I am not really sure why it wouldn't work as it does if I run it through the cmd prompt. Would anybody know why this is?
I am running this on a Windows Server 2008 R2 cloud instance, and I am attempting to copy a working setup that so that we can move it to an offsite location.
It turns out that cygwin didn't like the directory that the Client-SDK was in. Once I reinstalled it to C:/IBM/Informix/Client-SDK everything started working. I am not sure if the problem was the parentheses or the spaces, but getting them out of the path seemed to do the trick.
Looks more like a problem with using a combo of backslashes and slashes in your PATH environment. Slashes for *nix, backslashes for WIN and DOS. CLIENT, DBLOCALE, DBDATE, etc. can be set in your servernane.cmd file in WIN/DOS and in .profile, .cshrc, .login, etc. depending on the *nix shell you're using. You can install the Informix binaries and other supporting files in any directory you like, as long as INFORMIXDIR environment points to the installed directory. I have 11.70.FC6 installed in C:\INFORMIX and my dbspaces in C:\DBSPACES.
When I try to use ediff-revision under Emacs 23.2.1 for a CVS-managed file, I receive the following error in the *ediff-errors* frame, instead of commencing directly to the ediff results:
cygwin warning:
MS-DOS style path detected: c:/Users/BILL/AppData/Local/Temp/misc.cpp.~1.10~
Preferred POSIX equivalent is: /cygdrive/c/Users/BILL/AppData/Local/Temp/misc.cpp.~1.10~
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
My problem is that I have already set that CYGWIN environment variable option "nodosfilewarning", so I have no idea why I am receiving this error.
In fact, I can verify this right from an inferior shell under the same Emacs instance:
> set | grep -i nodos
CYGWIN=nodosfilewarning
I am running Cygwin 1.7.9-1 under Windows 7, in case this may be relevant (and I never had this problem before upgrading from Cygwin 1.5 to 1.7).
Any idea how to get rid of this error?
P.S. A subsequent call to ediff-revision succeeds without triggering this warning.
The CYGWIN variable is parsed when the first process in a Cygwin process tree is invoked. Hence, setting it in .bashrc or something like that is too late. A good place to set it is in the global Windows environment, under Control Panel->System->Advanced->Environment Variables.
I added (setenv "CYGWIN" "nodosfilewarning") to setup-cygwin.el. That seems to take care of the problem without, AFAICT, creating other problems. I also filed Emacs bug #14541 for this.
From within emacs, you may also:
M-x setenv
CYGWIN
nodosfilewarning
as an immediate alternative to altering setup-cygwin.el.