Re: Emacs is coming back - all pleased?
Angelo Graziosi [EMAIL PROTECTED] writes: 2) XEmacs comes with AUCTEX, so if one should use xemacs-emacs-common, WHY not adding auctex to it? Alternatively Emacs22 should have its own AUCTEX package. The compilations for Emacs and XEmacs are incompatible. In general, sharing packages between Emacs and XEmacs makes little sense, since the editors both expect .el files and .elc files to be in the same directory, and the .elc files are incompatible. So Emacs22 should have its own AUCTeX package. In my opinion as AUCTeX maintainer, so should XEmacs: the AUCTeX packaged with XEmacs is utterly outdated and quite unmaintained. The AUCTeX project provides an up-to-date XEmacs package on its download page URL:http://www.gnu.org/software/auctex/download.html. Due to policy reasons (in the name of quality assurance), the XEmacs project will not distribute this package actively maintained by upstream. Anyway: it would be infeasible to share AUCTeX between both editors (as a note aside: Debian has devised a system for sharing packages which suffers from the problem that neither Emacs/XEmacs developers nor Emacs/XEmacs itself properly understand it, and I have my doubts that the Debian people in charge of it do, either), and using the old buggy AUCTeX distributed as part of XEmacs' sumo tarball would be an extremely bad idea, anyway. -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with setup.exe
cuicui [EMAIL PROTECTED] writes: David Kastrup a écrit : Hi, I have downloaded and non-installed a number of packages. Now I call setup.exe in a batch file with setup -n -N -d -A -L -q -R %CYGWIN_HOME% and this works in that it installs what is cached in the local directory, but!!! just the default minimal selection, not what I have additionally selected and fetched using setup.exe. Since this is part of an automated installation procedure, this is quite a nuisance. Is there any way to tell setup.exe what else to install when it _is_ already cached? Hi, Just add a virtual package in your setup.ini in the Base category that depends on the packages you need. I think there is no way to tell Cygwin to install every packages in the local directory on the command-line mode. Be careful, the setup.ini is erased with a fresh one each time you launch install from internet. Ok, I'll try to see whether I get this done. Basically, is there a problem with creating a complete fake setup.ini that just lists every package I have downloaded as belonging to category Base, with no dependencies? If it will get overwritten when installing from internet, there would not seem to be much of a problem, right? -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem with setup.exe
Hi, I have downloaded and non-installed a number of packages. Now I call setup.exe in a batch file with setup -n -N -d -A -L -q -R %CYGWIN_HOME% and this works in that it installs what is cached in the local directory, but!!! just the default minimal selection, not what I have additionally selected and fetched using setup.exe. Since this is part of an automated installation procedure, this is quite a nuisance. Is there any way to tell setup.exe what else to install when it _is_ already cached? -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with stat
Eric Blake [EMAIL PROTECTED] writes: Matthew Woehlke mw_triad at users.sourceforge.net writes: If the named file is a symbolic link, the stat() function shall continue pathname resolution using the contents of the symbolic link, and shall return information pertaining to the resulting file if the file exists. This says nothing about what is returned if the file does not exist. RETURN VALUE Upon successful completion, 0 shall be returned. Otherwise, -1 shall be returned and errno set to indicate the error. Matthew is right. I have no doubt that he is right about what programs do. I am just pointing out that it involved an advanced degree in lawyering and sophistry to extract this kind of information from the standard. Which makes the standard badly worded, at the very least. And if that isn't enough to convince you, you should also read POSIX XBD 4.11, which talks all about pathname resolution. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html Yes, that is more clear. But it does not help one standard that a different standard is more careful in its wordings. Since stat() is not one of the special functions that operates on symlinks, it MUST resolve whatever the link points to, and if the link is broken, then it must behave the same way it does for any other resolution failure, ie. in this case, fail with ENOENT. In short, it is IMPOSSIBLE for stat() to give you a struct stat that passes S_IFLNK on a compliant platform. Give up your argument now. There are enough of us on this list that know POSIX and SUSv3 that you will not win. Whatever. I fail to see that the first wording of the standard is so unambiguous that I would bet my life on S_ISLNK never returning true on a dead link accessed with stat, when the implementor was of the opinion of following the standard's wordings. In short: I was not talking about what behavior to _implement_ but rather what behavior to _expect_. And given the fuzzy wording, I find the intent to be reasonably well hidden here. -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with stat
Eric Blake [EMAIL PROTECTED] writes:
According to Erich Dollansky on 6/26/2007 6:57 AM:
if (stat (/usr/X11R6/share/doc/lesstif-0.94.4/html/Lessdox, Stat)
== 0)
{
printf (Mode: %lX\n, (unsigned long) Stat.st_mode);
if (S_ISDIR (Stat.st_mode))
printf (Directory flag is set.\n);
The result is the same as before.
I do not get the message 'Link flag is set.'
And that is correct behavior. It is a bug if you can ever make
stat() or fstat() report S_ISLNK.
fstat, yes. But shouldn't stat be able to report S_ISLNK on a broken
link?
--
David Kastrup
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Problem with stat
Eric Blake [EMAIL PROTECTED] writes: According to David Kastrup on 6/26/2007 7:10 AM: fstat, yes. But shouldn't stat be able to report S_ISLNK on a broken link? No. It must fail with ENOENT. http://www.opengroup.org/onlinepubs/009695399/functions/stat.html No information there. component of a path has nothing to do with symlink resolution. -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with stat
Eric Blake [EMAIL PROTECTED] writes: David Kastrup dak at gnu.org writes: fstat, yes. But shouldn't stat be able to report S_ISLNK on a broken link? No. It must fail with ENOENT. http://www.opengroup.org/onlinepubs/009695399/functions/stat.html No information there. component of a path has nothing to do with symlink resolution. If the named file is a symbolic link, the stat() function shall continue pathname resolution using the contents of the symbolic link, and shall return information pertaining to the resulting file if the file exists. This says nothing about what is returned if the file does not exist. In other words, if file is a broken symlink, symlink resolution MUST take place, Nothing whatsoever in the above states this. Only the behavior when the resulting file exists is specified. at which point, the brokenness of the symlink means that stat() MUST fail with ENOENT because a component of the path does not exist. I don't see where this is apparent from the wording. Cygwin is correct here, as is Linux. They don't conflict, but that is all. -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Batch installation, possibly without setup.exe?
Hi, if I want to install a version of Cygwin without user interaction (optimally just dropping a bunch of files via unzip), is that feasible? In particular: does setup.exe fiddle with the registry or other files that can't be just overwritten as a whole? Obviously, one might want to have PATH adjusted, but apart from that? Thanks, -- David Kastrup -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
