Re: Problem installing Cygwin 1.7.25 64 bit on W7 and W8
On Sun, Sep 1, 2013 at 5:38 PM, nu774 honeycom...@gmail.com wrote: Same experience here. I once pushed continue on the incomplete download error dialog by mistake, that resulted in uninstalling of the selected packages for updates, including cygwin (except for cygwin1.dll). Did the same thing, in my case even cygwin1.dll is gone, previous version doesn't install either. Looking into setup.ini from various mirrors I can see that all files have size 0. This is also consistent with setup.log which has an error like: Download .../x86_64/release/cygwin/cygwin-1.7.25-1.tar.bz2 wrong size (2708993 actual vs 0 expected) Cygwin is currently unusable, so sad... -- 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
Re: Problem installing Cygwin 1.7.25 64 bit on W7 and W8
On Sun, Sep 1, 2013 at 10:30 PM, Robert Pendell wrote: Which mirror did you try? Did you try another mirror? I just checked my private mirror and it shows fine. I primarily use ftp.heanet.ie, but I tried mirrors.kernel.org and a couple random mirrors, all of them show the same problem. For example if you look at these directories: http://mirrors.kernel.org/sourceware/cygwin/x86_64/ ftp://ftp.heanet.ie/pub/cygwin/x86_64/ Then you will see setup.ini having a modification time of 03:22 GMT, which timestamp is this file on your private mirror? Best regards, Alexey. -- 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
Re: Cygwin Set up - Migrate to new machine
On Mon, Sep 28, 2009 at 11:42 PM, Kevin Holleran kdaw...@gmail.com wrote: I am building a new laptop and was wondering if there was a way I could copy some ini or setup file from cygwin to the new one so that the cygwin installer would install the same packages as opposed to having to go through and tweak the install to get it the way I want it again. Assuming you are using Cygwin 1.7 I've created a script for myself, that allows me to make a stripped down install cmd that would reinstall all packages that I had installed, see: http://kitsu.ru/cygwin-reinstall-cmd.py It has mirror and cygwin directory names hard coded (change them to what you use), and prints out commands that you can redirect to e.g. cygwin-reinstall.cmd. Unless you have way too many packages it should also fit into Windows command line limit... -- 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
[1.7] cygwin allows writing to readonly files
Hi, $ echo foo test.txt $ chmod 0444 test.txt $ echo bar test.txt This succeeds, even though the file is readonly, and permissions don't allow writing to the file. What's even stranger is that other programs (i.e. Notepad and other editors) can't write to this file, because there are no writing permissions on the file. How does cygwin 1.7 manages to bypass NT permissions in this case? Currently this breaks ExtUtils::MakeMaker, because it expects readonly files not to be writable and test fails. -- 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
Re: [1.7] cygwin allows writing to readonly files
On Mon, Aug 10, 2009 at 5:25 PM, Corinna Vinschencorinna-cyg...@cygwin.com wrote: That's a bug in your testsuite. I assume you're running the tests as administrator, right? Administrators have the right to write to all files, even R/O files, according to POSIX rules. Your test would fail on Linux as well, if you're running it as root. Well, it's not my testsuite, but yes, I'm running under administrator account. But it makes me wonder, how does it work? Do you change ACLs temporarily? Anyway, it means there is a bug in perl, because on Linux: r...@kitsu:~# touch test.txt r...@kitsu:~# chmod 0444 test.txt r...@kitsu:~# perl -e 'print writable\n if -w test.txt' writable On Cygwin 1.7 perl thinks that the file is not writable. -- 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
Re: [1.7] cygwin allows writing to readonly files
On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkovsna...@gmail.com wrote: Anyway, it means there is a bug in perl, because on Linux: On second though, it is actually bug in Cygwin. Programs and libraries expect superuser behavior only when user id is zero, which is clearly not the case in Cygwin 1.7. I think that maybe only local administrator account should be assigned user id 0, and that only local administrator should be allowed reading/writing files that it has no access to. -- 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
Re: Perl bug (was Re: [1.7] cygwin allows writing to readonly files)
On Mon, Aug 10, 2009 at 8:40 PM, Corinna Vinschencorinna-cyg...@cygwin.com wrote: That's a bug in perl. There are other OSes out there which have root-like permissions for non-0 uids. Perl should use the access() function to check for read/write/execute permissions, which always returns the correct result independent of the uid of the current user. Ah, so it is actually possible on other OSes, I didn't know that. Then maybe you're right. Thanks for clarifying. -- 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
Re: [1.7] git svn cannot rebase
On Thu, Aug 6, 2009 at 10:04 AM, Reini Urbanrur...@x-ray.at wrote: peflagsall maybe? Does it even apply on Windows XP? I thought ASLR is a Vista feature. -- 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
Re: [1.7] git svn cannot rebase
On Tue, Aug 4, 2009 at 1:30 PM, Alexey Borzenkovsna...@gmail.com wrote: I just noticed that for several cygwin1.dll versions git svn is not working. Here's the repo I can reproduce it with and cygcheck -s -r: Ok, I did a fresh minimal install on a clean Windows XP at home and the bug doesn't happen. I guess I'll try reinstalling at work and see if the bug would still happen. -- 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
[1.7] git svn cannot rebase
I just noticed that for several cygwin1.dll versions git svn is not working. Here's the repo I can reproduce it with and cygcheck -s -r: http://kitsu.ru/cygwin17-psyco2-git.tar.bz2 http://kitsu.ru/cygwin17-psyco2-cygcheck.log.gz aborzen...@ng-ws0212 /cygdrive/d/Alex/_work/git-tracking/psyco/psyco2-git $ git svn rebase 6 [main] perl 4592 C:\cygwin-1.7\bin\perl.exe: *** fatal error - unable to remap C:\cygwin-1.7\bin\cygz.dll to same address as parent: 0x19FC != 0x67FF 16 [main] perl 4508 fork: child 4592 - died waiting for dll loading, errno 11 rebaseall was of no help. :( -- 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
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Wed, Jun 3, 2009 at 6:27 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? I am strongly against it. Because, as I showed earlier, this case: for filename in `ls`; do windowsprogram.exe $filename end Should work. Since filenames use cygwin's encoding (UTF-8 for C locale, or the value of LANG), arguments conversion should use it too. It would be confusing otherwise. -- 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: Win2k Command Window Can't Execute G++
On Sun, May 31, 2009 at 6:36 PM, Roger Head rlinco...@yahoo.com wrote: U... e no, no, that's too easy. There must be a harder way to do it. As an alternative you can try looking into my http://git.kitsu.ru/mine/shell-wrapper.git (use snapshot link for topmost commit if you don't have git and don't know how to clone) Basically, for any command in bin you can create a .exe file in C:\cygwin\bin-public, which you can later add to your PATH. If will work for any cygwin executable, because it goes thru a wrapper that runs the command with cygwin's exec functions. First run make, then look at makewrappers.cmd for example of how I use it myself. -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Fri, May 29, 2009 at 8:22 PM, Edward Lam edw...@sidefx.com wrote: I think there is still a bug here? I set LANG=C, then shouldn't be just NOT doing any encoding, thus work? If I do this on Linux, it works. If I use a cygwin compiled app, it also works. On Linux, internally, system uses multibyte strings (it is encoding agnostic even), but on Windows, system uses unicode strings, so cygwin has to decode your byte sequences somehow to pass them to non-cygwin processes as unicode (the fact that cygwin now understands unicode is a huge plus to me). In earlier discussions it was decided that cygwin C locale should use utf-8 encoding, because file system internally uses unicode it's the safest default to represent all possible filenames, etc. In previous cygwin versions, your byte sequences were just silently converted using your system's codepage (by the system itself, even), so if you want the old behavior you should set LANG=en_US.CP1252. The only bug here is that the arguments are truncated instead of using some kind of a replacement character, is it related to some posix complience, like with wprintf? -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 12:10 AM, Edward Lam edw...@sidefx.com wrote: Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision to use UTF-8 for the C locale is questionable. Not at all, because utf-8, as far as I understand, is used for communication with the system in this context, and does not force anything to the application. Most modern unixes use utf-8 nowadays, it means that even if you have a C locale your terminal outputs text in utf-8, your input is utf-8, your filenames are utf-8 (well, not really, but the rest of the system sees them that way). Same stuff here, except that launching non-cygwin processes is communication with the system as well, and it needs conversion. And where is conversion there is always possible loss of data. One way or the other. It seems to me that it would be much safer to use the SYSTEM DEFAULT code page (ie. the return value of the system GetACP() function) for CYGWIN instead, ensuring compatibility for the large class native Windows applications that are non-Unicode, non-CodePage aware. It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I think it's very bad that changing LANG can result in a truncated *command line*, that has nothing to do with printf. The printf in the code was just for testing. The HUGE bug is that the application gets the WRONG NUMBER OF ARGUMENTS. No, the bug is not that it gets wrong number of arguments. In fact, Windows has no concept of arguments, only C runtime does, which parses the command line. If command line is truncated, then C runtime will have missing arguments when it tries to parse it. I mentioned wprintf because recently I was wondering why mkpasswd/mkgroup had a strange truncating behavior with russian usernames and it turned out that wprintf, when it can't encode some characters, stops right there and returns an error code. But, honesly, who ever checks return codes from printf? Here might be something similar. When constructing command line some function is called and can't encode some character, returns error status, but it's never checked, and you get truncated command line. And btw, I'm not cygwin developer here, I'm just a speculating user right now, because I haven't been searching this problem in the code. -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 1:04 AM, Edward Lam edw...@sidefx.com wrote: Alexey Borzenkov wrote: It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I must be missing something here. Suppose you have a default Russian code page, with LANG unset (ie. cygwin 1.7 uses UTF-8). Now, if you're using any non-Unicode, non-CodePage aware, native application to create a Russian filename, isn't Windows going to convert the filename from the Russian code page into UTF-16 for storage in NTFS? If that is the case, and then you do an ls from cygwin 1.7, aren't you going to get the wrong filename displayed? ie. interoperability with non-Unicode, non-CodePage aware native applications will be broken for you too with the current default cygwin 1.7 behaviour. Or is this, not a case that you care about and you *only* use cygwin applications? No, it is precisely that I care about both ends of interoperability. Here is a hypotetical situation: for filename in `ls`; do someprogram $filename done Here, when I use russian Windows and I don't have LANG set (or when I have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So both, russian and european/chinese/japanese filenames will be valid. Now there are three possibilities: 1) someprogram is a cygwin application, then it must be that $filename will be passed as is, without any conversions 2) someprogram is a unicode application, then it will have a correct unicode argument 3) someprogram is an ansi application, then Windows (cygwin has nothing to do with it) will convert its unicode arguments to system's codepage (cp1251 for Russian) and any character that can't be encoded will be replaced with question marks. This is solely someprogram's fault and cygwin has nothing to do with it. All I'm trying to say is that on Windows (since WinNT) arguments are always in unicode. It just so happens that when ansi applications call other ansi applications with a sequence of bytes, it first gets converted to unicode, then back to ansi, and you get the same sequence of bytes. But the arguments are always characters, not bytes. -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 1:21 AM, Edward Lam edw...@sidefx.com wrote: Here's some more investigation: [...] So note that even when I'm seems to be an UNICODE-AWARE child process, I'm still getting a truncated command line. In fact, call GetCommandLineW() directly seems to give a truncated command line as well. And again, you must have misunderstood me. In my opinion: truncation is a bug (should use replacement character, or fail exec altogether), expecting utf-8 is not (if you tried to cat your copyright.txt on a Linux box that uses utf-8, what would you expect to see on the screen?) -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Thu, May 28, 2009 at 7:28 PM, Edward Lam edw...@sidefx.com wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. -- 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: Calling Cygwin to start a shellscript
On Sat, May 16, 2009 at 2:51 AM, Brian Mathis brian.mat...@gmail.com wrote: What I have done is associate files with a .sh extension to run the bash.exe file. Works for me, but I'm not sure if it pulls in all the environment variables - but I don't need them. If you ever need those environment variables, take a look at my http://git.kitsu.ru/mine/shell-wrapper.git (though there's no documentation at the moment, I hope people would understand it on their own). In short, you create C:\cygwin\bin-public directory, where tiny executable proxies are generated for any command you like (like bash, git, ruby, etc.) and a configuration file that describes environment changes. You can add bin-public to your path, it's almost as fast as executing the command directly from bin (my primary reason for creating shell-wrapper was extremely long time it took to bash --login), and there are no commands in your path that you don't need (or that might clash with something else). I also usually create a cygwin.exe wrapper (it's all in the batch file), which allows me to type cygwin command [parameters] directly from FAR Manager/cmd prompt... -- 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/
[1.7] mkpasswd and mkgroup ignore user and group names with national characters
I'm in a domain at work and previously used mkpasswd -d and mkgroup -d to populate /etc/passwd and /etc/group files. Unfortunately, we mostly use Russian versions of Windows (especially on servers) here and most built-in user and group names (like Administrator, Domain Users, etc.) are localized. With cygwin 1.5 these names were successfully exported by mkpasswd/mkgroup, however with cygwin 1.7 all such usernames are silently ignored and don't appear in the output. Since my primary group is Domain Users every time I execute cygwin.bat I see this: Your group is currently mkgroup. This indicates that neither your gid nor your pgsid (primary group associated with your SID) is in /etc/group. The /etc/group (and possibly /etc/passwd) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group Note that the -d switch is necessary for domain users. Is it some bug or was it a design decision? -- 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: [1.7] bug in printf and %ls
On Fri, May 15, 2009 at 11:43 AM, Alexey Borzenkov sna...@gmail.com wrote:
I'm in a domain at work and previously used mkpasswd -d and mkgroup -d
to populate /etc/passwd and /etc/group files. Unfortunately, we mostly
use Russian versions of Windows (especially on servers) here and most
built-in user and group names (like Administrator, Domain Users, etc.)
are localized. With cygwin 1.5 these names were successfully exported
by mkpasswd/mkgroup, however with cygwin 1.7 all such usernames are
silently ignored and don't appear in the output.
And I found why. It appears that there's a bug in printf with %ls that
will refuse to print the string completely if the wide string for %ls
cannot be represented in current charset. It's interesting that
sometimes it behaves differently. For example:
$ mkpasswd -C
NDGAMES\aborzenkov:unused:11721:10513:U-NDGAMES\aborzenkov,*sidremoved*:/home/aborzenkov:/bin/bash
$ mkgroup -C
NDGAMES\
Notice that in the second case it somehow managed to print domain name
and separator before failing.
Another example:
#include stdio.h
#include locale.h
int main(int argc, char** argv)
{
setlocale(LC_ALL, en_US.CP1252);
printf('%ls', L\u0410\u0411\u0412);
return 0;
}
Prints nothing, i.e. it doesn't print neither of single quotes. If it
couldn't represent those characters, I think it should either ignore
them, or try to display them with SO-UTF-8. Making printf call fail
like that is, imho, really unexpected.
--
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: [1.7] bug in printf and %ls
On Fri, May 15, 2009 at 1:30 PM, Alexey Borzenkov sna...@gmail.com wrote: And I found why. It appears that there's a bug in printf with %ls that will refuse to print the string completely if the wide string for %ls cannot be represented in current charset. [...] Prints nothing, i.e. it doesn't print neither of single quotes. So, as it seems printf on linux abort like that too, although it manages to print first single quote first. So the only remaining question is why newlib doesn't print the first single quote. -- 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/
[1.7] Problem with national characters in directory names when using UTF-8 charset
There is something strange going on with national characters in
directory names when using Cygwin 1.7 with UTF-8. Here's a sample
session:
# test.rb
# -*- coding: utf-8 -*-
filename = File.expand_path(test.txt)
puts filename
puts File.open(filename) { |f| f.read }
# test.txt
This is a test
C:\cygwin\home\aborzenkov set LANG=en_US.UTF-8
C:\cygwin\home\aborzenkov mkdir проверка
C:\cygwin\home\aborzenkov copy test.rb проверка
C:\cygwin\home\aborzenkov copy test.txt проверка
C:\cygwin\home\aborzenkov C:\cygwin\bin\ruby проверка/test.rb
/usr/bin/ruby: No such file or directory -- проверка/test.rb (LoadError)
C:\cygwin\home\aborzenkov C:\cygwin\bin\cat проверка/test.txt
This is a test
C:\cygwin\home\aborzenkov cd проверка
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ruby test.rb
/home/aborzenkov/▒??▒N?▒??▒??▒?ч▒N?▒??▒?°/test.txt
This is a test
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\cat test.txt
/usr/bin/cat: test.txt: No such file or directory
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ls -al
/usr/bin/ls: cannot open directory .: No such file or directory
Why is it that some commands can't accept russian character in
filenames, yet work within russian directories, and other can open
filenames with russian paths, but can't work within russian
directories? It seems extremely weird to me. :-/ Also, I'm wondering
about this discrepancy:
C:\cygwin\home\aborzenkov C:\cygwin\bin\ruby /bin/irb
irb(main):001:0 Dir.chdir(проверка)
= 0
irb(main):002:0 File.expand_path(*)
=
/home/aborzenkov/\320\277\321\200\320\276\320\262\320\265\321\200\320\272\320\260/*
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ruby /bin/irb
irb(main):001:0 File.expand_path(*)
=
/home/aborzenkov/\016\320\277\016\321\200\016\320\276\016\320\262\016\320\265\016\321\200\016\320\272\016\320\260/*
Notice how for the same current directory (one where cygwin session
has done chdir to russian directory on its own, another where cygwin
session was started in russian directory) give different results for
File.expand_path in ruby. If I understood cygwin documentation
correctly, \016 is supposed to appear only for character that cannot
be represented with current charset (which is utf-8), yet in second
case they appear all over the place. The same thing is happening with,
for example, bash, which shows garbled pwd output when started from
within russian directory, yet works well when I chdir to that
directory manually.
What's going on?
--
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/
Asciidoc 8.2.3+ breaks git manpages
Hi everyone, I wonder if nobody noticed this yet, but since Asciidoc 8.2.3 git manpages are broken in regard that gitlink macro is not handled correctly, and what you see when issuing git --help is a lot of [1], [2], [3], etc that are completely unreadable. I found this offending line in asciidoc.conf: # Explicit so they can be nested. (?su)[\\]?(?Pname(http||link)):(?Ptarget\S*?)(\[(?Pattrlist.*?)\])= If you add \b in front on (http||link) the macro then behaves correctly (because it will match only when link is not preceded with other letters). This is upstream bug and I wonder who is at fault here (git or asciidoc?). -- 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/
