[PATCH] Upgrade pdfgrep to 2.1.2
Attached a tiny patch for your consideration to upgrade pdfgrep to 2.1.2 (from 1.4.1). For replies please keep me in CC, since I am not registered to any of the cygwin mailing lists. Thanks, J. pdfgrep-2.1.2.patch Description: Binary data -- 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
clang-family: error after --help (inconsistent command line options)
Hello, I can confirm the bug reported in early April (https://sourceware.org/ml/cygwin/2018-04/msg00021.html, author cc'ed): The following friends of the clang-... application family (5.0.1-2) show this error when calling, e.g., exe --help: : CommandLine Error: Option 'disable-symbolication' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options - clang-check.exe - clang-format.exe - clang-import-test.exe - clang-offload-bundler.exe - clang-rename.exe After looking around a bit in the net it could well be that something is linked into the apps twice, but not sure where if this is a cygwin issue or not: - https://bugs.llvm.org/show_bug.cgi?id=22543 - https://reviews.llvm.org/rL240104 Please let me know if any more info required. Many thanks! -- 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: gawk 4.1.4: CR separate char for CRLF files
Hi Wolfgang, First of all, many thanks for your interesting experience report and the constructive remarks. On Mon, 14 Aug 2017 10:36:23 +, Vermessung AVT - Wolfgang Rieger wrote: > Another solution which we have been using for many years now, though it > might not be feasible for you: Yes, you are right, unfortunately: We make extensive use of gawk extensions to upgraded with gawk in tandem. Thus we will move forward with the ongoing gawk development. > We very rarely update Cygwin. We have been using Cygwin for some 15+ > years now. We use tools like gawk (hundreds of scripts), head, tail, sort, etc. > that we are using in shell scripts running under cmd.exe (no Unix shells > involved). I soon realized that upgrades of Cygwin may cause troubles with > existing scripts, so we only update if we really need to (e.g.: New > functionality that would be important, 32 to 64 bit shift, eventually new > Windows versions, bugs we needed to be fixed). > > I have followed the discussions about the CR/LF behaviour changes in the > past attentively and decided not to update in near future, because that > would lead to a massive problem with many hundreds of scripts - hoping > that sometimes there will be a change in gawk again. Agree - this is the same setting here. Furthermore, we run our heavy processes on a semi-annual basis within a more than tight time frame. So cygwin's update came pretty much out of the blue in the late minute, because since the last reporting cycle we have not used gawk. An unpleasant surprise with heavy potential time issues if we had not taken the decision on how to deal with the changed situation. And as you are saying below ... > What is Unix-like or OS-like or Posix-like behaviour in that context? You could > argue that gawk interprets line endings like the underlying OS does (i. e., > gawk reads LF in Unix and CR/LF in Win), or it interprets line endings in a > Unix-style no matter of the underlying OS used. That's a developer's decision > in my opinion. True. And the developers of gawk opted - with a heavy heart I believe - to have gawk swallow CRs. > But since with pipes or output redirection gawk used to write no CRs even in > previous versions, we already had the problem that gawk had to accept > *both* inputs, LF with or without CR. That worked widely fine so far, since > most Windows and other application SW we use accept both record formats, > fortunately (we had issues with SW upgrades of other vendors no longer > accepting pure LF, but that only concerned a very small number of scripts). > With the new approach in Cygwin that seems to be broken, so we did not > upgrade Cygwin since then (we currently use gawk 4.1.3). Yes, this is our basis of SW selection process as well, but we march with gawk's version as it nicely develops needing a gawk version reading files and pipes of any LF and CRLF kind out of the box. > Of course the reason for that really annoying CR/LF thing is the arrogance > and ignorance of MS, which caused innumerable of useless developers' > hours when I think of the endless discussions and changes in Cygwin; but MS > is the one who defines the standards because of its very market power, so > we have to deal with it, if we like or not. I'd definitely prefer to use Unix for > its powerful tools, but most of the SW we use is simply not available for Unix, > and MS does not provide gawk etc. So we have to deal with that CR/LF issue > in a pragmatic rather than in a more, say, philosophical approach: We need > to run our scripts with as little changes as possible. So that's why we upgrade > Cygwin as seldom as possible. It is a "living system", yes, which is great on > the one side - but can be annoying in everyday practice. We are squared into the Windows world as well. So there's no way out of that. So far I was more than happy that the gawk code comes with the feature to silently swallow CRs (cf. the code reference with the exact code line in my previous posting) and that was used until the last update. Now that things - from our point of view - tremendously changed, we were urged to run a decision process looking at alternatives (I listed in my first email). The evaluation in the past days led us to the decision to use another source of bilingual versions of gawk and friends (i.e. they read CRLF and CR without any additional hint). This is what the user can opt for. > In my opinion there should be at least an option for gawk to accept both LF > and CR/LF line endings equally, preferably with a system variable so that > there is no need to change the command line call of gawk at all. That's what I > vote for. Fully agree - for this I would have been pretty much in favor as well. Something close to this I was having in mind in my first posting. > Kind regards, > Wolfgang Best regards, J. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:
RE: gawk 4.1.4: CR separate char for CRLF files
Hi Roger,
On Wed, 9 Aug 2017 07:03:24 +, Roger Krebs wrote:
> I've added a BEGIN section at the beginning awk sript file setting the
record
> separator explicitly for the input file (RS) as well as for the output
file (ORS):
>
> BEGIN {
> RS="\r\n"
> ORS="\r\n"
> }
> {
>... your script
> }
>
> Especially the RS parameter wasn't necessary in the past but now it is.
Which is a pretty much of a pain when there is no easy fallback solution
provided in case a major change is applied. E.g. for sed - if I understand
the reference to sed in https://cygwin.com/ml/cygwin/2017-08/msg00033.html
correctly - a separate switch '-b' is added. For the latest gawk version I
cannot see anything like that which means that all of our awk scripts run
against cygwin's gawk do break without any tweak unless I am missing
anything here.
This is - to say the least - unpleasant in the light of what Cygwin claims
to be, namely 'a large collection of GNU and Open Source tools which provide
functionality similar to a Linux distribution on Windows' (from the top of
the start website www.cygwin.com). Again, admittedly I did not dive into the
discussion and the substance of the reasoning to make this move to gawk |
sed | grep.
Now I can see the following *easy* solutions to the very situation here
(input only for now):
1 - Inserting the BEGIN section as you suggested into more than 1k scripts
(not feasible due to additional regression test workload)
2 - Calling 'gawk -vRS=\r\n -vORS=\r\n' instead of 'gawk' (hack to turn back
the additional the latest gawk's complexity, wrapper needed)
3 - Wrapping a d2u/u2d pipe solution (additional app and wrapper needed
again)
4 - Using another compiled version of gawk which does *not* disable the
out-of-the-box gawk feature to swallow CRs (cf., e.g.,
http://git.savannah.gnu.org/cgit/gawk.git/tree/awkgram.y#n3543), i.e.
without the artificial obstacle to now know the EOL type of the input file
ahead of running gawk.
> It works in all my cases. The only disadvantage: you have to know what
kind
... plus the disadvantage to systematically amend all the scripts instead of
having an external solution
> of files you want to handle in the awk script. The same awk script will
not
> work for DOS files as well as for linux files.
... another issue originated by the change and which didnt exist before.
> Best
>
> Roger
Please don't get me wrong, but this raises a real issue here and I am not
sure which rationale other than 'let's get more of the Linux-feel' drove the
decision.
All the best,
J.
> -Ursprüngliche Nachricht-
> Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im
> Auftrag von Jannick
> Gesendet: Mittwoch, 9. August 2017 02:48
> An: cygwin@cygwin.com
> Betreff: RE: gawk 4.1.4: CR separate char for CRLF files
>
> On Tue, 08 Aug 2017 16:23:40 -0700 (PDT), Steven Penny wrote:
> > On Wed, 9 Aug 2017 01:15:08, "Jannick" wrote:
> > > the current version 4.1.4 of gawk appears to unpleasantly treat CR
> > > for CRLF files, i.e. CR is not gracefully swallowed, but is a
> > > separate
> character.
> > >
> > > This makes some, if not all, of the scripts we are working with here
> > > useless, unless the input files are converted to LF which certainly
> > > is not feasible. IIRC the issue did not show up some versions back.
> > >
> > > Is this a bug - or am I missing something here?
> >
> > Learn to read:
> >
> > http://cygwin.com/ml/cygwin/2017-08/msg00033.html
>
> Thanks - quickly done.
>
> The link reveals that CRLF/LF conversion is now mandatory to work with
> cygwin's gawk on DOS machines. As far as I can see there is no legacy
> solution like for, e.g., sed (-b switch) to have an easy solution for the
issue,
> especially when invoking gawk from makefiles (piping).
>
> I consider this bad news while admittedly not fully understanding the
whole
> background of the move which is not necessary for now.
--
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: gawk 4.1.4: CR separate char for CRLF files
On Tue, 08 Aug 2017 16:23:40 -0700 (PDT), Steven Penny wrote: > On Wed, 9 Aug 2017 01:15:08, "Jannick" wrote: > > the current version 4.1.4 of gawk appears to unpleasantly treat CR for > > CRLF files, i.e. CR is not gracefully swallowed, but is a separate character. > > > > This makes some, if not all, of the scripts we are working with here > > useless, unless the input files are converted to LF which certainly is > > not feasible. IIRC the issue did not show up some versions back. > > > > Is this a bug - or am I missing something here? > > Learn to read: > > http://cygwin.com/ml/cygwin/2017-08/msg00033.html Thanks - quickly done. The link reveals that CRLF/LF conversion is now mandatory to work with cygwin's gawk on DOS machines. As far as I can see there is no legacy solution like for, e.g., sed (-b switch) to have an easy solution for the issue, especially when invoking gawk from makefiles (piping). I consider this bad news while admittedly not fully understanding the whole background of the move which is not necessary for now. -- 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
gawk 4.1.4: CR separate char for CRLF files
Dear All, the current version 4.1.4 of gawk appears to unpleasantly treat CR for CRLF files, i.e. CR is not gracefully swallowed, but is a separate character. This makes some, if not all, of the scripts we are working with here useless, unless the input files are converted to LF which certainly is not feasible. IIRC the issue did not show up some versions back. Is this a bug - or am I missing something here? Thanks, J. - living on Win10 -- 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: [PATCH] glob.h (i686-pc-mingw32) b/c wrong function prototype of function 'glob'
On Sat, 8 Jul 2017 13:45:38 +0100, Jon Turney wrote: > The i686-pc-mingw32 toolchain was removed from Cygwin a while ago [1]. Many thanks - very enlightening! Obviously I missed this info. So a useless patch. > [1] https://cygwin.com/ml/cygwin-announce/2016-03/msg00069.html -- 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: [PATCH] glob.h (i686-pc-mingw32) b/c wrong function prototype of function 'glob'
On Jul 03, 2017 at 01:12 PM, Jannick wrote: > of function 'glob' > > On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote: > > > This is, in fact, the wrong mailing list. The files for the mingw > > cross build environment are maintained via the mingw-w64-public > > mailing list on sourceforge, see > > > > https://sourceforge.net/p/mingw-w64/mailman/ > > > > Ideally you provide your patches there. > > Thanks for this - just for the record: > https://sourceforge.net/p/mingw-w64/mailman/message/35924907/ The mingw-w64 list turned out to be the wrong list, too, unfortunately. For the MinGW32 distribution glob.h is maintained here https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/mingwrt/include/glob.h. I am not sure what the code basis of i686-pc-mingw32 is, so am back here on this list with the patch. Maybe there is someone out here who knows how which version of glob.h finds its way into cygwin's i686-pc-mingw32 distribution. Kind regards, J. -- 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: [PATCH] glob.h (i686-pc-mingw32) b/c wrong function prototype of function 'glob'
On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote: > This is, in fact, the wrong mailing list. The files for the mingw > cross build environment are maintained via the mingw-w64-public > mailing list on sourceforge, see > > https://sourceforge.net/p/mingw-w64/mailman/ > > Ideally you provide your patches there. Thanks for this - just for the record: https://sourceforge.net/p/mingw-w64/mailman/message/35924907/ > HTH, > Corinna Many thanks, J. -- 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
[PATCH] glob.h (i686-pc-mingw32) b/c wrong function prototype of function 'glob'
Attached a tiny patch to i686-pc-mingw32' glob.h which remedies a function
prototype definition error thrown upon compilation.
I am hoping that this is the correct one of cygwin's mail-lists, please
advise otherwise.
Thanks,
J.
---
C:/cygwin32/usr/i686-pc-mingw32/sys-root/mingw/include/nppBackup/glob.h.2017
-06-25_142140.bak Tue Jul 16 00:34:26 2013
+++ C:/cygwin32/usr/i686-pc-mingw32/sys-root/mingw/include/glob.h Sun
Jun 25 14:21:40 2017
@@ -142,7 +142,8 @@
#define GLOB_INLINE static __inline__ __attribute__((__always_inline__))
GLOB_INLINE int glob
-( const char *__pattern, int __flags, int (*__errfunc)(), glob_t *__data )
+( const char *__pattern, int __flags, int (*__errfunc) (const char *, int),
glob_t *__data )
{ return __mingw_glob( __pattern, __flags, __errfunc, __data ); }
GLOB_INLINE void globfree( glob_t *__data )
glob.h.patch
Description: Binary data
--
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
[gnumeric v1.12.31] ssconvert cannot find xcall32(.dll) in fn-math and html plugin folders
Hi, I am not sure if this is a bug: running a xlsx2tex conversion ssconvert --export-type=Gnumeric_html:latex a.xlsx a.tex results in the error messages ** (ssconvert:12292): WARNING **: Unable to open module file "/usr/lib/gnumeric/1.12.31/plugins/fn-math/xlcall32". ** (ssconvert:12292): WARNING **: Unable to open module file "/usr/lib/gnumeric/1.12.31/plugins/html/xlcall32". I could solve this by copying \lib\gnumeric\1.12.31\plugins\excelplugins\xlcall32.dll to both \lib\gnumeric\1.12.31\plugins\fn-math\xlcall32.dll \lib\gnumeric\1.12.31\plugins\html\xlcall32.dll However, still the error message below, while the tex file is created. 2 [main] ssconvert 13684 cygwin_exception::open_stackdumpfile: Dumping stack trace to ssconvert.exe.stackdump Apologies if anything with this posting is not fine, as I am pretty much a newbie here to Cygwin. Thanks, J. -- 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
