xsltproc from libxstl-1.1.15-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1Hi Gerrit,I'm using xsltproc from .bat-Files under cmd/command and so far had no problems with Backslashes for paths on the command line (at least when the last component is divided by a proper slash from the actual file name).>>> Using libxml 20622, libxslt 10115-CVS1027 and libexslt 812-CVS1027 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 <<<Thus (ini2bat.xsl contains with >set -H2k=G:\hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xmlyields:Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" warning: failed to load external entity "lib/readconf.xsl" compilation error: file G:\hans2k/util/confxml/ini2bat.xsl line 7 element importxsl:import : unable to load lib/readconf.xsl and with >set -H2k=G:/hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xml yields: Loaded URL="G:/hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G:///hans2k/util/confxml/lib/readconf.xsl" ID="(null)" ...The previous version worked o.k. (for me): >>> Using libxml 20620, libxslt 10114-CVS1011 and libexslt 812-CVS1011 xsltproc was compiled against libxml 20620, libxslt 10114 and libexslt 812 libxslt 10114 was compiled against libxml 20620 libexslt 812 was compiled against libxml 20620 <<<Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G%3A%5Chans2k/util/confxml/lib/readconf.xsl" ID="(null)" ... At the moment I cannot see any possibilty to "slashify" my file paths prior to calling xsltproc.unfortunately I got lost studying the sources. In uri.c of libxml is no special path processing for CYGWIN, but there hasn't, since cygwin takes care of paths? My guess is, that test on "\" in IS_UNWISE cancels processing of those paths in several routines in uri.c thus it would be wise to (re?)introduce some CYGWIN-specific normalization in xmlCanonicPath in uri.c . However the comment "This really need to be cleaned up by someone with a Windows box" for the win32-specific normalization is not really encouraging...Do you have any ideas?simple testcase below: - -- foo.xsl --http://www.w3.org/1999/XSL/Transform";> - -- -- bar.xsl - http://www.w3.org/1999/XSL/Transform";> - call asxsltproc --load-trace u:/bla/foo.xsl u:/bla/foo.xslvs.xsltproc --load-trace u:\bla/foo.xsl u:/bla/foo.xslGreetings Thomas Berger -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDhjeGENVh3bB0lwMRAmvgAKCnhu9gGaw329cj+cC/3vyMDpdaOACff6oz G5WZgEcRuq8awMThZCxt8TE= =su83 -END PGP SIGNATURE- -- 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/
[no subject]
Woah Gerrit, WDYDWMLF (what did you do with my line feeds)? o.k. since the libxml maintainer choose to forward my struggles to the list, here comes the readable form: I'm using xsltproc from .bat-Files under cmd/command and so far had no problems with Backslashes for paths on the command line (at least when the last component is divided by a proper slash from the actual file name). >>>>>> Using libxml 20622, libxslt 10115-CVS1027 and libexslt 812-CVS1027 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 <<< Thus (ini2bat.xsl contains with >set -H2k=G:\hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xml yields: Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" warning: failed to load external entity "lib/readconf.xsl" compilation error: file G:\hans2k/util/confxml/ini2bat.xsl line 7 element import xsl:import : unable to load lib/readconf.xsl and with >set -H2k=G:/hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xml yields: Loaded URL="G:/hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G:///hans2k/util/confxml/lib/readconf.xsl" ID="(null)" ... The previous version worked o.k. (for me): >>>>>> Using libxml 20620, libxslt 10114-CVS1011 and libexslt 812-CVS1011 xsltproc was compiled against libxml 20620, libxslt 10114 and libexslt 812 libxslt 10114 was compiled against libxml 20620 libexslt 812 was compiled against libxml 20620 <<< Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G%3A%5Chans2k/util/confxml/lib/readconf.xsl" ID="(null)" ... At the moment I cannot see any possibilty to "slashify" my file paths prior to calling xsltproc. unfortunately I got lost studying the sources. In uri.c of libxml is no special path processing for CYGWIN, but there hasn't, since cygwin takes care of paths? My guess is, that test on "\" in IS_UNWISE cancels processing of those paths in several routines in uri.c thus it would be wise to (re?)introduce some CYGWIN-specific normalization in xmlCanonicPath in uri.c . However the comment "This really need to be cleaned up by someone with a Windows box" for the win32-specific normalization is not really encouraging... Do you have any ideas? simple testcase below: -- foo.xsl -- http://www.w3.org/1999/XSL/Transform";> - -- bar.xsl ----- http://www.w3.org/1999/XSL/Transform";> call as xsltproc --load-trace u:/bla/foo.xsl u:/bla/foo.xsl vs. xsltproc --load-trace u:\bla/foo.xsl u:/bla/foo.xsl Greetings Thomas Berger -- 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/
[no subject]
Hello, the following bug seems to have been introduced recently: A command rsync -avPz -e ssh /cygdrive/g/coop/a-dat/tst/tst_90.ald \ duckling:/cygdrive/e/exposed/kirn yields: >>> building file list ... 1 file to consider wrote 89 bytes read 20 bytes 31.14 bytes/sec total size is 7438770 speedup is 68245.60 <<< but the size of the resulting file is 7.438.826. (rsync detects the difference and transfers the file again the next time. and again. and again ...) Both machines involved run cygwin with openssh-3.9p1-1 and rsync 2.6.2-2, both /cygdrive's are mounted textmode ($CYGWIN also contains nobinmode). Downgrading to rsync 2.6.2-1 on the target machine resolves the problem. viele Gruesse Thomas Berger -- 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/
cron functionality regression?
Hello, >From http://sourceware.org/ml/cygwin/2007-04/msg00319.html : > The changes (listed in /usr/share/doc/cron/CHANGES) don't appear to break > compatibility with 3.0. this seems to be a version of vixie cron which (contrary to the previous one) consistently (e.g. also in the manpage) does not (yet?, any more?) support crontabs in /etc/cron.d . How sad. Thomas Berger -- 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: Perl documentation inaccessible via 'perldoc'.
Andrew Schulman wrote:
>> >> [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.22
>> >> $ perldoc ExtUtils::MakeMaker
>> >> Error in tempfile() using ./XX: Parent directory (./) is not
>> >> writable
>> >> at /usr/lib/perl5/5.8/Pod/Perldoc.pm line 1483
> >
> > tempfile() is trying to create the tempfile in the current directory,
> > rather than a standard temporary directory such as /tmp. 'perldoc
> > File::Temp' says that if you don't specify a tempfile directory,
tempfile()
> > puts it in the location returned by File::Spec::tempdir(). Normally
that
> > should be /tmp. I wonder, do you have TMPDIR set? Try setting it, e.g.
File::Spec identifies the OS as "cygwin" and accordingly
File::Spec->tempdir() is File::Spec::Cygwin->tempdir() and tests
$ENV{'TMPDIR'}, /tmp, and C:/temp in that order.
Each of these will be tested for definedness, existence and writablity,
so usually this yields an U**Xish "/tmp" under Cygwin. Only when neither
of these three satisfies the restrictions, "." is returned (unchecked).
It might be argued that $ENV{'TMPDIR'}, /tmp, $ENV{'TMP'}, $ENV{'TEMP'},
C:/temp might be a more appropriate list (since c:/temp usually is
not world-writable on WinNT ff), but the difference would be only in the
situation where Cygwin's /tmp is not writable, which IMO is undesirable
anyway.
Thomas Berger
--
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: Request for running a test application
Hi Corinna, Output for a CD burner with a DirectCD / UDF / packet writing formatted CDRW (compression is on) on W2k as drive E:. Device Type: 2 Characteristics: 123 Volume Name: Serial Number : 153278523 Max Filenamelength : 127 Filesystemname : Flags : 6 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE and this would be a DAV volume mounted on S: on WinXP: Device Type: 7 Characteristics: 10 Volume Name: <> Serial Number : 0 Max Filenamelength : 255 Filesystemname : Flags : 20002 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE HTH Thomas Berger -- 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: HEADS UP:Problem with svn under latest snapshot.
It could be a matter of interference with TortoiseSVN. Joe Smith wrote: > Just in case you were not aware, Something has broken svn in the latest > snapshot. (Actually at least the two most recent snapshots have this > problem). > > Here is the error: "svn: Can't move '.svn/tmp/entries' to > '.svn/entries': Permission denied" > > > LS output: > $ ls -al .svn > total 2 > drwxr-xr-x+ 6 Owner None 0 Aug 7 16:11 . > drwxr-xr-x+ 3 Owner None 0 Aug 7 16:09 .. > -r--r--r-- 1 Owner None 192 Aug 7 16:09 entries ... > > $ ls -al .svn/tmp > total 1 > drwxr-xr-x+ 5 Owner None 0 Aug 7 16:11 . > drwxr-xr-x+ 6 Owner None 0 Aug 7 16:11 .. > -rw-r--r-- 1 Owner None 192 Aug 7 16:11 entries ... > > If I were to take a guess, i'm thinking it the "-r--r--r--" permission > on .svn/entries that is causing the problem. > Something probably changed in the permissions handling, causing the > breakage. Accidentally, I had the same problem today and found the following helpful: < http://www.cygwin.com/ml/cygwin/2006-09/msg00081.html > (I didn't have to disable Icon overlays completely, just restrict them to "explorer only"). The cause seemed to be that "entries" additionally has the Windows R/O attribute set and cannot be deleted by svn. Some of the #ifdef WIN32 in libsvn_subr/io.c look interesting (if one argues that the Cygwin port should put some more efforts in coexisting nicely with native svn tools). viele Gruesse Thomas Berger -- 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/
[no subject]
Corinna Vinschen schrieb: > Nevertheless, the problem must be some other BLODA. I have sshd running > on every OS since NT4 and I have no trouble running it. and logging in > to any admin or non-admin account. If it's really a Cygwin bug, it's > quite non-deterministic since logging in via the normal old-style > public/private key pair works fine for me. > > [...time passes...] I have an purely anecdotical observation to share, which may or may not be related to the OP's problem: Last week I disboxed a brand new Windows 7 x64 system and started preparing it as a substitute for my desktop system. Things got crowdy in my office so the new box was initially placed out of arm's reach (this is the key information for understanding the rest ;-). (Essentially) I Installed Ultra VNC, installed Cygwin 1.7, ran ssh-host-config, joined my (Active Directory, Win2k hosted FWIW) domain, logged in as myself and transferred the contents of my .ssh directory, then ran ssh-user-config. I then had [first randomly but on trying harder ever more deterministic ;-] trouble with passwordless login via the domain account but was unable to (casually) debug the problem (no amount of -v's whereever applied gave me any clue to what really went wrong). Passwordless login to the local admin account however worked, as did login to my domain account with user/password (after modification of authorized_keys). My observation was that the failure was correlated to fresh reboots of the box (which happen quite often in that stage of a box' live cycle and unfortunately were reinforced by my approaches to solve the problem ;-) My conclusion after some time spend testing was to first once either log on or at least connect via UltraVNC (not even actually log in) with the credentials of my (some? sorry I did not follow all possible ramifications) domain account for passwordless login to succeed. After this everything went smooth regardless of current console sessions, i.e. the remedy was not tied to the domain user being logged in but to having been logged in previously. Since the situation changed now (the new box is not any more sitting next to me but moved in front of me thus no need to log on remotely after reboot) I did not investigate any further. It might be that UltraVNC has some undetected BLODAness or that some component of the ssh beast relies on initialization? effects of previous logins for some versions of windows x64??. viele Gruesse Thomas Berger -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[no subject]
Hi Cygwinners, On "XP Mode" on Windows 7 x64 I encounter the identical problem as described in < http://cygwin.com/ml/cygwin/2007-04/msg00630.html >. For a host drive mapped as G: <-> \\TSCLIENT\g "ls" yields bash-3.2$ ls /cygdrive/g ls: reading directory /cygdrive/g: Permission denied The same share mapped as Y: <-> \\\g works as desired (because of a huge M$-induced performance penalty this kind of mount is unfortunately not an option for me) Specific Info: bash-3.2$ /usr/lib/csih/getVolInfo /cygdrive/g Device Type: 7 Characteristics: 10 Volume Name: <> Serial Number : 1516020298 Max Filenamelength : 255 Filesystemname : Flags : 3e700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : TRUE bash-3.2$ /usr/lib/csih/getVolInfo /cygdrive/y Device Type: 7 Characteristics: 10 Volume Name: <> Serial Number : 1516020298 Max Filenamelength : 255 Filesystemname : Flags : c700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE What to do? viele Gruesse Thomas Berger -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[no subject]
> * On Mon, Mar 01, 2010 at 09:45:46AM -0800 David Rothenberger wrote: >> On 3/1/2010 5:43 AM, Alan Burn wrote: > >> So I think I've made a little progress here. I still don't have a >> solution, but I can now reproduce the problem. > > Doesn't cygwin 1.7 add the .exe suffix when writing (some?) binary > files? I seem to remember to have readabout this being a problem before > the release of 1.7.1 here in this mailing list. I think Corinna was > speaking with someone about this. I experienced the introduction of ".exe" suffixes when rsyncing a directory hierarchy with many checked out svn repositories: File names like freetbl.exe.svn-base were changed on transport to freetbl.exe.svn-base.exe I did not investigate whether this behaviour was triggered by the file magic number or just the ".exe" inside the name Cheers Thomas Berger -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
