I have gnu tools and mingw on my windows XP notebook. When I try awk in mingw, end result is really disappointing. If I use awk in windows XP's command line windows, everything works fine. please check out attached screen shots for details.
We don't support gnutools versions of software. If you want to execute awk use the one provided by MSYS. You should find it in the /bin directory when in the MSYS shell.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Awk provided within MSYS doesn't work properly and that's why I reported this bug.
If you check out the attached files, you will see that earlier version of awk in GNU tools works perfectly fine. However awk within msys shell doesn't.
I'd like to use MinGw shell over windows' command prompt. And I am just trying to get your attention to a problematic spot.
Good luck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The Awk provided within MSYS doesn't work properly ...
Kind of a sweeping statement, isn't it? It's also incorrect -- I've been using MSYS awk for years, and it has ALWAYS worked PERFECTLY for me.
It's not 100% obvious from your screen-shots -- it would have been better if you'd attached ACTUAL FILES, (blacklist.txt in particular) -- but I suspect that Earnie's guess is on the money: blacklist.txt is a CRLF delimited file.
MSYS awk, BY DESIGN, works with binary mode streams, so CR has no special meaning for it. You are concatenating multiple input lines into one comma separated output line, but EVERY comma in the output, (except the first in your example), is preceded by a CR (residual binary data from the preceding line). This causes the cursor to move back to the start of the DISPLAY line, when output is directed to the console, before emitting each of the commas, leading to the effect observed in your screen-shot.
> ... and that's why I reported this bug.
This isn't a bug in MSYS awk, as such; you just have to anticipate and handle those unwanted CR bytes. Either filter your input through dos2unix, as Earnie suggests, so the input stream has line endings the way God intended, or handle them explicitly within your awk script, which I might write thus:
awk '{
sub("\r$","");
if( x == "" ) x = $0;
else x = x "," $0
}
END {
print x
}'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK.. dos2unix seems to fix the problem. Looks like confusion between windows and unix line endings were causing the problem.
I think I made a mistake by assuming that minGW would use Windows line endings instead of unix line endings as it is designed to sit on top of windows. I think I jumped the gun when I noticed that both msys and gnu tools use similar awk under the hood.
Anyways. Thanks for the prompt response. My apologies if I offended anyone by my "sweeping" statement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
awk behavior in windows XP's own command line window - version included
awk behavior in wingw shell - version included
environment details.
We don't support gnutools versions of software. If you want to execute awk use the one provided by MSYS. You should find it in the /bin directory when in the MSYS shell.
The Awk provided within MSYS doesn't work properly and that's why I reported this bug.
If you check out the attached files, you will see that earlier version of awk in GNU tools works perfectly fine. However awk within msys shell doesn't.
I'd like to use MinGw shell over windows' command prompt. And I am just trying to get your attention to a problematic spot.
Good luck
You need to
dos2unix blacklist.txt
MSYS is emulating UNIX and requires \n line endings.
<blockquote>I have gnu tools and mingw on my windows XP notebook.</blockquote>
This doesn't tell me you have MSYS installed. There is another project distributing GNU tools and that is what I thought you meant.
> The Awk provided within MSYS doesn't work properly ...
Kind of a sweeping statement, isn't it? It's also incorrect -- I've been using MSYS awk for years, and it has ALWAYS worked PERFECTLY for me.
It's not 100% obvious from your screen-shots -- it would have been better if you'd attached ACTUAL FILES, (blacklist.txt in particular) -- but I suspect that Earnie's guess is on the money: blacklist.txt is a CRLF delimited file.
MSYS awk, BY DESIGN, works with binary mode streams, so CR has no special meaning for it. You are concatenating multiple input lines into one comma separated output line, but EVERY comma in the output, (except the first in your example), is preceded by a CR (residual binary data from the preceding line). This causes the cursor to move back to the start of the DISPLAY line, when output is directed to the console, before emitting each of the commas, leading to the effect observed in your screen-shot.
> ... and that's why I reported this bug.
This isn't a bug in MSYS awk, as such; you just have to anticipate and handle those unwanted CR bytes. Either filter your input through dos2unix, as Earnie suggests, so the input stream has line endings the way God intended, or handle them explicitly within your awk script, which I might write thus:
awk '{
sub("\r$","");
if( x == "" ) x = $0;
else x = x "," $0
}
END {
print x
}'
OK.. dos2unix seems to fix the problem. Looks like confusion between windows and unix line endings were causing the problem.
I think I made a mistake by assuming that minGW would use Windows line endings instead of unix line endings as it is designed to sit on top of windows. I think I jumped the gun when I noticed that both msys and gnu tools use similar awk under the hood.
Anyways. Thanks for the prompt response. My apologies if I offended anyone by my "sweeping" statement.