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.
Related
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 am using ubuntu 12.04. Every time I start my bash terminal and every time when I finish typing a command(and press enter) , I get this message:
ERROR: ld.so: object '/usr/lib/liblunar-calendar-preload.so' from
LD_PRELOAD cannot be preloaded: ignored.
It is weird.
So what is the environment variable LD_PRELOAD used for? And what is the going on behind the scene?
Thanks.
The linker takes some environment variables into account. one is LD_PRELOAD
from man 8 ld-linux:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF
shared libraries to be loaded before all others. This can be
used to selectively override functions in other shared
libraries. For setuid/setgid ELF binaries, only libraries in
the standard search directories that are also setgid will be
loaded.
Therefore the linker will try to load libraries listed in the LD_PRELOAD variable before others are loaded.
What could be the case that inside the variable is listed a library that can't be pre-loaded. look inside your .bashrc or .bash_profile environment where the LD_PRELOAD is set and remove that library from the variable.
If you want to make sure that the library is loaded if and only if the program lunar-calendar-gtk is launched, you can apply this:
You set the environment variable per command by prefixing the command with it:
$ LD_PRELOAD="liblunar-calendar-preload.so" printenv "LD_PRELOAD"
liblunar-calendar-preload.so
$ printenv "LD_PRELOAD"
$
You can then choose to put this in a shell script and make lunar-calendar-gtk a symlink to this shell script, replaceing the original referencee. This effectively makes sure that the library is loaded everytime the original application is executed.
You will have to rename the original lunar-calendar-gtk to something else, which might not be too intriguing as it possibly may cause issues with uninstallation and upgrading. However, I found it useful with a former version of Skype.
Thanks for the responses. I think I've solved the problem just now.
Since LD_PRELOAD is for setting some library proloaded, I check the library that ld preloads with LD_PRELOAD, one of which is "liblunar-calendar-preload.so", that is not existing in the path "/usr/lib/liblunar-calendar-preload.so", but I find a similar library "liblunar-calendar-preload-2.0.so", which is a difference version of the former one.
Then I guess maybe liblunar-calendar-preload.so was updated to a 2.0 version when the system updated, leaving LD_PRELOAD remain to be "/usr/lib/liblunar-calendar-preload.so". Thus the preload library name was not updated to the newest version.
To avoid changing environment variable, I create a symbolic link under the path "/usr/lib"
sudo ln -s liblunar-calendar-preload-2.0.so liblunar-calendar-preload.so
Then I restart bash, the error is gone.
It means the path you input caused an error. In your LD_PRELOAD command, modify the path like the error tips:
/usr/lib/liblunar-calendar-preload.so
I got this type of error when I installed Citrix client on my Raspberry Pi. In short there is a file /etc/ld.so.preload. The library my system was complaining about was listed in that file. I commented it out with a # and system stopped complaining.
The solution that worked for me was using sudo vim and going into /etc/ld.so.preload
I then just removed the line
/usr/local/lib/AppProtection/libAppProtection.so
Then I just saved the file and everything worked without issues.
When I executed the following command, everything became better.
unset LD_PRELOAD
You can check /etc/ld.so.preload file content
I fix it by:
echo "" > /etc/ld.so.preload
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
I am working on an Android App and just start to use Cygwin for ndk-build. When I build my c lib, the output may disappear while scrolling down fast. The same will happen when I try to make other libraries based on Linux through Cygwin. Although I can reopen the cmd window and make the project again to see the output that really matters, such as, warnings, errors, but it's really annoying to do it again and again.
Does someone encounter the same question? How to solve it?
Thanks.
What terminal are you using? By default cygwin just runs bash under the usual windows cmd.exe, which is definitely not all that great; installing and using mintty (simplest way to do so is through cygwin's setup.exe) and setting the scrollback buffer size to accommodate your needs should fix the problem.
You could use other terminals too- PuTTY, xterm, rxvt, etc (even the KDE and Gnome terminals are available through Cygwin Ports)- but mintty is probably the best option for most cygwin users' needs (it's rather simple, small, and fast, and it integrates well with Windows).
Another option would be to redirect compilation messages: use > to redirect stdout to a file, overwriting it if it already exists, >> to append, and add a & if you want both stdout and stderr redirected, e.g. gcc mysource.c &>compilelog.
I have an escript file which runs fine from the command line, i.e.:
./escript_file
It is meant to be cron friendly and all paths are explicit but when I run it, it fails to compile saying that there are bad attributes.
The bad attributes in question are macro definitions:
-define(COOKIE, 'somecookie').
The Answer
Thanks to Geoff Ready's suggestion I investigated which version of Erlang was running by printing out init:script_id() which prints out a string like {"OPT APN 181 O1", "R13B"} and, sure enough the command line and cron versions were picking up different versions.
The script had an initial line:
#!/usr/bin/env escript
and the operating system was 'finding' Erlang for me. The different environment variables of cron meant that a different erlang was being picked up (Geoff's first answer, and one I kinda knew but couldn't see how it would affect things).
The solution is then to force the version with a starting line of:
#!/usr/local/lib/erlang/erts-5.7.3/bin/escript
Postscript
There was also a different Ubuntu apt-get install of an earlier version of Erlang (in a different location to the source install) and an errant 64-bit install...
The cron environment just kept falling back to older and more obscure installs, failing all the while :(
Perhaps cron is picking up a different version of erlang in the path. Erlang R12B documentation says that escript ignores preprocessor directives besides include_lib. Erlang R13B documentation says that the preprocessor is run on the file. That would definitely explain the difference in behavior.
If it is working fine from the command line, a likely cause is a difference in environment variables for your interactive shell versus when cron runs the script.
Changing #!/usr/bin/env escript to #!/usr/local/bin/escript at the top of the file will work if the Erlang versions are the same.