Re: [ITP] astrometry.net-0.38-1
Well, well. I'm grateful for esp. the hours Chuck put into this, and for having at least seen the process and all, but I suppose it's time to end this -- I just can't bear to watch losing all the votes so bravely fought for ;-) AstroTortilla is fine with a custom repo. All we ever wanted was to be able to install astrometry.net with Cygwin's setup.exe. There were two reasons for doing the ITP: 1) Astrometry.net is immensely useful, albeit for a relatively minor userbase (*), and it *will* be part of both Cygwin and all the other major/applicable distros, eventually 2) the thought never occured to me that custom repos are possible ... (*) So-called computerized GOTO telescopes have been sold by the unknown tens if not hundreds of thousands over the past 10-20yrs. ALL of them are essentially fixed by AstroTortilla, which critically relies on Astrometry.net. So it may well be that once the word gets out that there's a GOTO correction program just like the one Hubble Space Telescope uses, available for amateur astronomers and compatible with their trusty old mounts, we'll see some downloads. How many would we need for it to be considered significant enough? Is this document still valid? http://sourceware.org/cygwin-apps/package-server.html Anything else I need to know? Thanks once again for your time and effort! I'm sorry the lessons you gave me will go down the drain if I won't become a package manager ... ;-) -- jussi P.S. If this message doesn't turn out to be the end of story just yet, let it be known that I will have a look at building the package with dynamic linking, if package size is deemed a bigger issue than the superficially miniscule userbase. It's just there's work (as in paycheck) to do, and my family has very recently grown by one, so I'm in no greater hurry with this than before ...
Re: [ITP] astrometry.net-0.38-1
On 11/9/2011 5:00 AM, Jussi Kantola wrote: AstroTortilla is fine with a custom repo. All we ever wanted was to be able to install astrometry.net with Cygwin's setup.exe OK. How many would we need for it to be considered significant enough? No idea. Is this document still valid? http://sourceware.org/cygwin-apps/package-server.html Seems accurate -- but it's missing information about gpg security. I think you want Creating a custom Cygwin package server -- you probably don't want to create or host a full mirror. Anything else I need to know? Here's what I do, locally: top/setup.exe top/genini top/release/foo/foo-1.2.3-1.tar.bz2 top/release/foo/foo-1.2.3-1-src.tar.bz2 top/release/foo/setup.hint $ cd cygwin $ ./genini --recursive release setup.ini $ bzip2 -c setup.ini setup.bz2 Then, upload setup.ini, setup.bz2, the new tarballs and setup.hint to your website, replicating the directory structure (from top/ on down). Now, your users will have to invoke setup.exe with the -X, because otherwise setup.exe will expect the setup.ini/bz2 files to be signed. However, turning the security measures off is a problem, because then your users have no protection against corrupted files on the *main* mirrors, either. So, ideally, you would ALSO sign *your* setup.ini/setup.bz2 files. See http://www.cygwin.com/ml/cygwin-announce/2008-08/msg1.html Now, this still requires your end users to take an explicit action (see item (3i),(3ii),(3iii) in the referenced announcement.) You could enable them to do (3i) or (3iii) via a batch file that you distribute...or... See the cygwin-ports instructions for their users, here: http://sourceware.org/cygwinports/ In that case, the use of 'cygstart' implies that cygwinports would be *added* to an existing cygwin installation; hence a bare-windows installation would require two separate setup.exe runs (*). This is actually a /good/ thing, because it means there's no confusion between the standard cygwin installation on my box and the cygwinports cygwin installation on my box -- your end users would just have one, to which they've added the extra stuff. (*) future update runs of setup would handle both the 'standard' packages and the addons simultaneously. Thanks once again for your time and effort! I'm sorry the lessons you gave me will go down the drain if I won't become a package manager ... ;-) You're still managing a package...it just wouldn't be hosted as an intrinsic part of the cygwin distribution itself. -- Chuck
RFU: rtorrent-0.8.9-3
Due to a packaging error on my part, the '-2' release didn't actually contain rtorrent.exe. As a result please upload: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-3.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-3-src.tar.bz2 Please remove the '-2' release as it is incomplete. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: ATTENTION: Tcl/Tk transition
On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote: I obsoleted the following packages: db-2.7.7 db-3.1.17 db-3.3.11.2 db-4.0.14 db-4.1.25.3 db-4.2.52.5 db-4.3.29.1 db-4.4.20.4 IMO there is no reason to keep these old versions, as nothing in the distro depends on them. So if there are no objections, we can just outright remove them, and use _obsolete packages only for tcl-db*.*. did a rebuild of db-4.5.20.2 and added db-4.8.30 Something is wrong with these packages; the libdb* and tcl-db* packages aren't versioned. (BTW, I think the tcl-db4.5 should also be an _obsolete package, pointing to tcl-db4.8.) 5.x will follow later when the dust settles. That will be helpful. * ming [tcl-ming] (Dr. Volker Zell) new requires: tcl notes: needs a pkgIndex.tcl file to be of any use Done. It has now a pkgIndex.tcl file. * WordNet (Dr. Volker Zell) new requires: tcl tcl-tk notes: needs patches for security vulnerabilities, patches available from all major distros, e.g.: http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree Done, with all the paches and security fixes. These look good. You will find the packages under /home/vzell on sourceware. Just copy (scp -r) them over when everybody is ready. Thank you for your prompt attention to this. Since space on /home is tight, I have copied the ming and WordNet into a staging area until we're ready for the move. Thanks, Yaakov Cygwin/X
Re: RFU: rtorrent-0.8.9-3
On Wed, Nov 09, 2011 at 06:36:43PM -0500, Chris Sutcliffe wrote: Due to a packaging error on my part, the '-2' release didn't actually contain rtorrent.exe. As a result please upload: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-3.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-3-src.tar.bz2 Please remove the '-2' release as it is incomplete. Done. cgf
Re: ATTENTION: Tcl/Tk transition
On 10.11.2011 00:51, Yaakov (Cygwin/X) wrote: On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote: I obsoleted the following packages: db-2.7.7 db-3.1.17 db-3.3.11.2 db-4.0.14 db-4.1.25.3 db-4.2.52.5 db-4.3.29.1 db-4.4.20.4 IMO there is no reason to keep these old versions, as nothing in the distro depends on them. So if there are no objections, we can just outright remove them, and use _obsolete packages only for tcl-db*.*. did a rebuild of db-4.5.20.2 and added db-4.8.30 Something is wrong with these packages; the libdb* and tcl-db* packages aren't versioned. (BTW, I think the tcl-db4.5 should also be an _obsolete package, pointing to tcl-db4.8.) What do you mean with arent't versioned ? tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2 usr/lib/tcl8.5/ usr/lib/tcl8.5/db4.5/ usr/lib/tcl8.5/db4.5/cygdb_tcl-4.5.dll usr/lib/tcl8.5/db4.5/pkgIndex.tcl tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2 usr/bin/cygdb-4.5.dll usr/bin/cygdb_cxx-4.5.dll tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2 usr/lib/tcl8.5/ usr/lib/tcl8.5/db4.8/ usr/lib/tcl8.5/db4.8/cygdb_tcl-4.8.dll usr/lib/tcl8.5/db4.8/pkgIndex.tcl tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2 usr/bin/cygdb-4.8.dll usr/bin/cygdb_cxx-4.8.dll Ciao Volker
Re: ATTENTION: Tcl/Tk transition
On Thu, 2011-11-10 at 03:00 +0100, Dr. Volker Zell wrote: What do you mean with arent't versioned ? The package names themselves: tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2 The libdb packages must be libdb4.5 and libdb4.8. As for the -devel packages, perhaps we only need the latest one? tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2 If we need only one version of the Tcl bindings, fine (and it should come from 4.8), otherwise these need to be tcl-db4.5 and tcl-db4.8. Yaakov
Re: Built XWin on mingw - with patches
On 07/11/2011 19:36, Charles Wilson wrote: On 11/7/2011 1:10 PM, Jon TURNEY wrote: I see what you are trying to do here, but I'm not sure it actually adds any clarity. I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN are mutually exclusive, so '#if defined(WIN32) !defined(__CYGWIN__)' can just be written '#ifdef WIN32' But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 11/9/2011 1:46 PM, Jon TURNEY wrote: On 07/11/2011 19:36, Charles Wilson wrote: But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) But it's perfectly portable to check for __CYGWIN__ (or, for that matter, __MINGW32__) instead of WIN32 before #including w32api headers, because you know that the windows API will be available in those cases as well. The difference is, IF you do this (perfectly fine, legal, and portable) thing: #if defined(WIN32) || defined(__CYGWIN__) # include windows.h #endif then you can no longer rely on #if defined(WIN32) ...stuff that applies only for truly native windows (e.g. ...msvc or mingw), but not cygwin #endif even though both hunks above are legal and make perfect sense *in isolation*. The problem occurs when both hunks are present in the same translation unit -- and that's not always under your control. What if libjpeg's header does the first hunk (it doesn't, but assume that it does for argument's sake), and your project's headers only do the second? You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#include jpeg.h breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
XTerm metaSendsEscape not working
Hello, I find that adding the following: XTerm*vt100.metaSendsEscape: true XTerm*vt100.altSendsEscape: true XTerm*vt100.eightBitInput: false to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key handling. It still sends 0xF7 for meta-W, for example (or the UTF-8 equivalent, depending on how I set LANG in the environment). I've also tried this: XTerm*metaSendsEscape: true XTerm*altSendsEscape: true XTerm*eightBitInput: false to no avail. However, adding lines like the following: Meta KeyW: string(0x1b) string(w) \n to my XTerm*translations does the trick (though I would have to add a line like this for every key on the keyboard). The fact that this fixes it seems to be evidence that my problem really is at the XTerm level and not bash or readline or the X server or Windows key mappings or something like that. I'm using Windows 7 64-bit. Any ideas appreciated. Thank you. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XTerm metaSendsEscape not working
On Wed, 9 Nov 2011, Jesse Ziser wrote: Hello, I find that adding the following: XTerm*vt100.metaSendsEscape: true XTerm*vt100.altSendsEscape: true XTerm*vt100.eightBitInput: false to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key handling. It still sends 0xF7 for meta-W, for example (or the UTF-8 equivalent, depending on how I set LANG in the environment). I've also tried this: XTerm*metaSendsEscape: true XTerm*altSendsEscape: true XTerm*eightBitInput: false to no avail. However, adding lines like the following: Meta KeyW: string(0x1b) string(w) \n well, there's more than one aspect to the problem. xterm is looking for whatever is used for the modifier which corresponds to the meta key. But X doesn't have that as a standard modifier. So xterm looks at the modifiers and determines which one it is. It might be the same as an Alt-key, and it might not. So there's altSendsEscape as a workaround for that case. On the other hand, if there are translations using the key that xterm finds to be the meta key, then xterm refrains from using it as a modifier, unless (for example) the alwaysUseMods resource is set to true. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
What updates done after October 3 may affect gfortran built binaries?
This is again related to the failure of execution of a gfortran built binary (cannot execute binary, see thread http://cygwin.com/ml/cygwin/2011-11/msg00034.html ) In short, the main problem is that I can't build a successful binary from the FLEXPART fortran code (just google FLEXPART nilu if you are curious of what FLEXPART is) on a cygwin installation I did just over a week ago, but it builds and run without problem on an installation from October 3. I get no differences in warnings from the bad build compared to the good one, so I really don't know what to look for. So far I have come to the conclusion that this must be related to one or several changes in the cygwin distribution done after October 3. Through try and failure testing I found that this is not affected by gfortran/gcc as both gcc 4.3.4 and gcc 4.5.3 works. The latter hangs on '$EGREP' calls in the 'grib_api' (required library) configure script, but the workaround of changing to 'egrep' works fine. I have posted the output from strace, objdump and cygcheck for some of you to look at in the former thread, but it seem like this is far from a straight forward problem. I can see from the [ANNOUNCEMENT] posts that a few things in this cygwin distro have been updated since October 3 and I kindly ask if someone have an idea of what updates since then may cause a badly gfortran built binary if it has nothing to do with gcc alone? I will now start going through the updates and change back to versions yielding October 3 if possible. I think this is important since cygwin will give the opportunity to run and develop FLEXPART on Windows machines the way linux-users are used to. In addition, I also see a potential problem of other fortran software that people want to run under cygwin. Regards, Kåre
Re: What updates done after October 3 may affect gfortran built binaries?
On 11/9/2011 1:15 PM, Edvardsen Kåre wrote: This is again related to the failure of execution of a gfortran built binary (cannot execute binary, see thread http://cygwin.com/ml/cygwin/2011-11/msg00034.html ) In short, the main problem is that I can't build a successful binary from the FLEXPART fortran code (just google FLEXPART nilu if you are curious of what FLEXPART is) on a cygwin installation I did just over a week ago, but it builds and run without problem on an installation from October 3. I get no differences in warnings from the bad build compared to the good one, so I really don't know what to look for. So far I have come to the conclusion that this must be related to one or several changes in the cygwin distribution done after October 3. Through try and failure testing I found that this is not affected by gfortran/gcc as both gcc 4.3.4 and gcc 4.5.3 works. The latter hangs on '$EGREP' calls in the 'grib_api' (required library) configure script, but the workaround of changing to 'egrep' works fine. I have posted the output from strace, objdump and cygcheck for some of you to look at in the former thread, but it seem like this is far from a straight forward problem. I can see from the [ANNOUNCEMENT] posts that a few things in this cygwin distro have been updated since October 3 and I kindly ask if someone have an idea of what updates since then may cause a badly gfortran built binary if it has nothing to do with gcc alone? I will now start going through the updates and change back to versions yielding October 3 if possible. I think this is important since cygwin will give the opportunity to run and develop FLEXPART on Windows machines the way linux-users are used to. In addition, I also see a potential problem of other fortran software that people want to run under cygwin. Regards, Kåre my guess binutils http://cygwin.com/ml/cygwin-announce/2011-10/msg00028.html or some BLODA. I downloaded the http://zardoz.nilu.no/~flexpart/flexpart/flexpart_82-3.tar.gz but it is not clear to me how to replicate your build. make -f makefile.gfs_gfortran_32 fails here: --- $ make -f makefile.gfs_gfortran_32 gfortran -O2 -m32 -fconvert=little-endian -frecord-marker=4 -I/nilu2/home/flexpart/lib/gfortran/include -c -o writeheader.o writeheader.f includecom:685.22: Included at writeheader.f:50: common /globalr/ ! REAL 1 Error: The equivalence set for 'pplev' cause an invalid extension to COMMON 'globalr' at (1) .. --- Regards Marco -- 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: What updates done after October 3 may affect gfortran built binaries?
[...] I will now start going through the updates and change back to versions yielding October 3 if possible. I think this is important since cygwin will give the opportunity to run and develop FLEXPART on Windows machines the way linux-users are used to. In addition, I also see a potential problem of other fortran software that people want to run under cygwin. Regards, KÃre my guess binutils http://cygwin.com/ml/cygwin-announce/2011-10/msg00028.html or some BLODA. I downloaded the http://zardoz.nilu.no/~flexpart/flexpart/flexpart_82-3.tar.gz but it is not clear to me how to replicate your build. make -f makefile.gfs_gfortran_32 fails here: --- $ make -f makefile.gfs_gfortran_32 gfortran -O2 -m32 -fconvert=little-endian -frecord-marker=4 -I/nilu2/home/flexpart/lib/gfortran/include -c -o writeheader.o writeheader.f includecom:685.22: Included at writeheader.f:50: common /globalr/ ! REAL 1 Error: The equivalence set for 'pplev' cause an invalid extension to COMMON 'globalr' at (1) .. --- Regards Marco Thanx a lot, Marco for takng time! In order to replicate my build you need to install latest version of the grib_api library (http://www.ecmwf.int/products/data/software/download/grib_api.html) and istall it with jasper tar xvfz grib_api-1.9.9.tar.gz ./configure [--with-jasper=jasper path] make make install You then have to edit the makefile.ecmwf_gfortran_32 to have the right lib and include path's set for gfortran to find jasper and grib_api. The path's found in makefile.ecmwf_gfortran_32 are just showing where the programmers installed those lib's before distributing the FLEXPART software. If you get a successful build, it will still prompt an error since you will still miss some expected settings, but you will clearly see whether this is a bad binary or not. I will definitely try reinstalling an older version of binutils and give it a try. Thanx again for the advice. Regards, Kåre
Pass windows-style paths to the interpreter from the shebang line ?
Hello I would like to write a php script to run from my cygwin command line. I have the php CLI executable (php.exe) in PATH and I use #!/bin/env php as the first line of the .php script, and make it executable. The problem is that bash will than invoke the Win32 native php.exe binary with the Cygwin-style path of my script as the argument, and then php complains that it: `Could not open input file: /home/Adrian/usr/local/bin/parseLog.php´ Which is normal for php.exe, as it does not understand cygwin paths. I found no way around this problem. I would type `php /scriptname/´ myself but then the script name would no longer be searched on PATH and I would have to type 'D:\Local\cygwin\home\Adrian\usr\local\bin\parseLog.php' as the script name at all times. Is there a way around this ? Can cygwin detect the executable is not a cygwin application add pass in the right path name ? Thank you, Timothy Madden -- 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
Copy, paste and deleting characters in the openssh screen.
Hi, I am experiencing daily frustration because I do not know how to get the following features to my fingertips while controlling my Freenas/FreeBSD server from my openssh console on a remote Windows computer. 1) copy from windows document or browser and paste in the openssh console 2) copy from the openssh console and paste either on another line of the console or on a windows document 3) correct my openssh commands by deleting characters with the backwards stroke. Sometimes it works, sometimes not, it seems to depend on the type of login! The local user (Cygwin) seems to work, the root user on the freebsd server seems also to work, but another user on the freebsd server does not work : if I hit the backward stroke it prints a triangle (meaning I suppose unknown character) and there is no way to correct this but to send the wrong command and retype the whole command. With long commands it can be very frustrating. For 2) I have found the trick to redirect the output of the command to a file and then I read the file with an editor, and I can copy and paste it. But it works only for the output of the command, and not for the command itself. I guess the solution is fairly easy. This the newbie condition ;-) :) Gabier -- View this message in context: http://old.nabble.com/Copy%2C-paste-and-deleting-characters-in-the-openssh-screen.-tp32811323p32811323.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. I've not tried it to see how well it behaves though. -Jeremy -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On Nov 9 09:45, Jeremy Bopp wrote: On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. [...] I should have known that. Sorry Yaakov. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Pass windows-style paths to the interpreter from the shebang line ?
Sorry to reply again, but I hit send too early... On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. Does php not have an equivalent of the -S option (search the PATH for the named script) that perl and ruby have? I've used that many times to deal with cases where people have Windows-native builds of those tools instead of the Cygwin ones for whatever reason. -Jeremy -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On 11/9/2011 2:39 PM, Timothy Madden wrote:
Hello
I would like to write a php script to run from my cygwin command line.
I have the php CLI executable (php.exe) in PATH and I use
#!/bin/env php
as the first line of the .php script, and make it executable.
The problem is that bash will than invoke the Win32 native php.exe
binary with the Cygwin-style path of my script as the argument,
and then php complains that it:
`Could not open input file: /home/Adrian/usr/local/bin/parseLog.php´
Which is normal for php.exe, as it does not understand cygwin paths.
I found no way around this problem. I would type `php /scriptname/´
myself but then the script name would no longer be searched on PATH and
I would have to type
'D:\Local\cygwin\home\Adrian\usr\local\bin\parseLog.php' as the script
name at all times.
Is there a way around this ? Can cygwin detect the executable is not a
cygwin application add pass in the right path name ?
Thank you,
Timothy Madden
you need to use cygpath to convert posix path in window path
You could make a php.sh script like this to invoke your php.exe
with a window path
--
#!/bin/bash
for i in $(echo $PATH | tr ':' ' ')
do
a=$(find $i -name $1 -exec cygpath -w \{\}\; )
if ( [ $a != ] ) ; then
/full_cygwin_path/php.exe $a
exit
fi
done
--
Regards
Marco
--
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: Pass windows-style paths to the interpreter from the shebang line ?
On Nov 9 15:39, Timothy Madden wrote: Hello I would like to write a php script to run from my cygwin command line. I have the php CLI executable (php.exe) in PATH and I use #!/bin/env php as the first line of the .php script, and make it executable. The problem is that bash will than invoke the Win32 native php.exe binary with the Cygwin-style path of my script as the argument, and then php complains that it: `Could not open input file: /home/Adrian/usr/local/bin/parseLog.php´ Which is normal for php.exe, as it does not understand cygwin paths. I found no way around this problem. I would type `php /scriptname/´ myself but then the script name would no longer be searched on PATH and I would have to type 'D:\Local\cygwin\home\Adrian\usr\local\bin\parseLog.php' as the script name at all times. Is there a way around this ? Can cygwin detect the executable is not a cygwin application add pass in the right path name ? That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On 11/09/11 07:29, Corinna Vinschen wrote: I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? Corinna Hear, hear! -- Andrew DeFaria http://defaria.com Making music should not be left to the professionals. - Michelle Shocked -- 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: Copy, paste and deleting characters in the openssh screen.
On 11/9/2011 08:38, gabier wrote: Hi, I am experiencing daily frustration because I do not know how to get the following features to my fingertips while controlling my Freenas/FreeBSD server from my openssh console on a remote Windows computer. 1) copy from windows document or browser and paste in the openssh console 2) copy from the openssh console and paste either on another line of the console or on a windows document While you can get this to work with the default Cygwin terminal (cmd.exe), you would be better off installing the mintty package and using that for your terminal instead. You can configure it to behave like a typical xterm with respect to copying and pasting, so you may find that much more familiar. To copy and paste from a regular Windows program, highlight the text and press CRTL-C to copy as usual. Then go to your mintty window and paste using the method you configured for it in its configuration dialog. I think pressing SHIFT-INS should work by default, but there are other options available, including middle clicking (not the default IIRC). To copy and paste from the mintty window, highlight the text and then copy using the method you configured for mintty. I have my mintty configured to copy automatically when text is highlighted, but that's not the default as I recall. Once the text is copied, paste into a Windows program as usual with CRTL-V or paste back into the mintty window as discussed previously. 3) correct my openssh commands by deleting characters with the backwards stroke. Sometimes it works, sometimes not, it seems to depend on the type of login! The local user (Cygwin) seems to work, the root user on the freebsd server seems also to work, but another user on the freebsd server does not work : if I hit the backward stroke it prints a triangle (meaning I suppose unknown character) and there is no way to correct this but to send the wrong command and retype the whole command. With long commands it can be very frustrating. This may get corrected automatically by using mintty as your terminal, but it's really not a Cygwin-specific issue. I've had similar problems in the past and was able to work around them by pressing either CTRL-H or CTRL-BACKSPACE. My vague understanding of the problem is that the terminal sends a particular character in response to the backspace key, which is configurable in many terminals. Mintty is one such terminal, but the cmd terminal is not. Without the ability to change the character sent by the terminal program, you would need to be able to configure the remote applications to do the right thing with whatever character *is* sent, but that can be a tall order due to the different ways you may have to configure each application. As I said, that is only my vague understanding of the problem, so it could be subtly or glaringly inaccurate. In any case, however, you will likely avoid the problem by using mintty. :-) -Jeremy -- 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
I try build cygwin-doc-1.7-1 without success.
Motivation to do this is to fix issue with incorrect info header for 'libc.info' and 'libm.info'. Instead: START-INFO-DIR-ENTRY * libm:: An ANSI-C conforming mathematical library. END-INFO-DIR-ENTRY 'libm.info' should contain: INFO-DIR-SECTION Cygwin START-INFO-DIR-ENTRY * libm: (libm).An ANSI-C conforming mathematical library. END-INFO-DIR-ENTRY With first variant 'info libm' show man page instead info page. Also Emacs from Cygwin show error: byte-code: No such node or anchor: libm With second variant all utils work fine. I get sources (cygwin-doc-1.7-1-src.tar.bz2) from mirror: $ tar jxf cygwin-doc-1.7-1-src.tar.bz2 $ cd cygwin-doc-1.7-1 $ mkdir _build _dist $ cd _build $ ../configure Get error in 'configure' on line: soc=$(find /usr/share/sgml/[Oo]pen[Ss]p* -name xml.soc) as my Cygwin installation have /usr/share/sgml/OpenSP path (last chat is capital). I fix 'configure' to: soc=$(find /usr/share/sgml/[Oo]pen[Ss][Pp]* -name xml.soc) and get 'Makefile'. 'Makefile' build failed with a lot of errors and warnings: $ make cygwin2info creating cygwin texi files for f in src/*/*.sgml; do \ docbook2texi -o src/texi -e no-idref -e no-significant -e no-valid -c /usr/share/sgml/OpenSP/xml.soc -d src/cygwin.dsl $f; \ done Using catalogs: /etc/sgml/sgml-docbook-4.5.cat, /usr/share/sgml/OpenSP/xml.soc Using stylesheet: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/cygwin.dsl Working on: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/api/cygwin-api.sgml nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd:116:17:E: X20AC is not a function name nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/ent/isoamsa.ent:42:29:E: X021B6 is not a function name nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/ent/isoamsa.ent:43:29:E: X021B7 is not a function name nsgmls:I: maximum number of errors (200) reached; change with -E option Done. Using catalogs: /etc/sgml/sgml-docbook-4.5.cat, /usr/share/sgml/OpenSP/xml.soc Using stylesheet: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/cygwin.dsl Working on: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/api/cygwin-ug-net.sgml nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd:116:17:E: X20AC is not a function name nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/ent/isoamsa.ent:42:29:E: X021B6 is not a function name nsgmls:URLhttp://www.oasis-open.org/docbook/xml/4.5/ent/isoamsa.ent:43:29:E: X021B7 is not a function name . nsgmls:I: maximum number of errors (200) reached; change with -E option Done. Using catalogs: /etc/sgml/sgml-docbook-3.0.cat, /usr/share/sgml/OpenSP/xml.soc Using stylesheet: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/cygwin.dsl Working on: /home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/api/dll_init.sgml nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/api/dll_init.sgml:2:0:E: prolog can't be omitted unless CONCUR NO and LINK EXPLICIT NO and either IMPLYDEF ELEMENT YES or IMPLYDEF DOCTYPE YES nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/api/dll_init.sgml:2:0:E: no document type declaration; will parse without validation nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/utils/utils.sgml:564:9: entity was defined here nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/utils/utils.sgml:564:28:E: reference to entity gt for which no system identifier could be generated ... nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/utils/utils.sgml:1810:12:E: reference to entity amp for which no system identifier could be generated nsgmls:/home/user/devel/cygwin/cygwin-doc-1.7-1/_build/src/utils/utils.sgml:590:57: entity was defined here make: *** [cygwin2info] Error 8 What do I wrong? I am build on Cygwin 1.7, is this correct or I must do this on Linux? Where VCS for this package? -- Best regards! -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On 09.11.2011 17:45, Jeremy Bopp wrote: On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. I've not tried it to see how well it behaves though. I have the full cygwin distribution installed with setup.exe and no php ? Where is the cygwin port for php ? Distributed separately ? Maintained separately ? Thank you, Timothy Madden -- 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: Pass windows-style paths to the interpreter from the shebang line ?
On Wed, Nov 09, 2011 at 11:15:47PM +0200, Timothy Madden wrote: On 09.11.2011 17:45, Jeremy Bopp wrote: On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. I've not tried it to see how well it behaves though. I have the full cygwin distribution installed with setup.exe and no php ? Where is the cygwin port for php ? Distributed separately ? Maintained separately ? http://lmgtfy.com/?q=what+is+cygwin+ports -- 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
gdb broken inside emacs (again? still?)
Hi all, Attempting to run gdb inside emacs with an executable file name argument (with or without --annotate=3) causes it to seg fault (no surprise, known issue). Running just `gdb' from emacs allows it to initialize, but attempts to load a file or indeed perform any command hang until a double-^C cancels the attempt (reporting C-c C-cquit). Ironically, even `quit' hangs, so you have to use ^D to exit. Debugging anything within emacs is thus completely impossible at this time. I've tried with a home-compiled gdb (same version) with no better luck. I'm building an emacs-23 from scratch, but I'm pretty sure I've already tried that before, without any conclusive improvement. I know this has come up before, and that it has been resolved before for me and for others, but it keeps recurring (usually whenever I actually need to debug something) and I can't find any reliable way to make the problem go away. Do the latest snapshots contain changes which should fix the problem? I'm on an win7-64 system, running the 13 Oct dll snapshot, after a rebaseall. Relevant package versions are below (setup.exe doesn't advertize any newer ones): binutils2.22.51-1 gcc44.5.3-3 gcc4-core 4.5.3-3 gcc4-g++4.5.3-3 gcc4-java 4.5.3-3 gdb 7.3.50-2 emacs 23.3-3 emacs-X11 23.3-3 Thanks, Ryan -- 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: gdb broken inside emacs (again? still?)
On 11/9/2011 4:44 PM, Ryan Johnson wrote: Hi all, Attempting to run gdb inside emacs with an executable file name argument (with or without --annotate=3) causes it to seg fault (no surprise, known issue). Running just `gdb' from emacs allows it to initialize, but attempts to load a file or indeed perform any command hang until a double-^C cancels the attempt (reporting C-c C-cquit). Ironically, even `quit' hangs, so you have to use ^D to exit. Debugging anything within emacs is thus completely impossible at this time. I've tried with a home-compiled gdb (same version) with no better luck. I'm building an emacs-23 from scratch, but I'm pretty sure I've already tried that before, without any conclusive improvement. I know this has come up before, and that it has been resolved before for me and for others, but it keeps recurring (usually whenever I actually need to debug something) and I can't find any reliable way to make the problem go away. Do the latest snapshots contain changes which should fix the problem? I'm on an win7-64 system, running the 13 Oct dll snapshot, after a rebaseall. Relevant package versions are below (setup.exe doesn't advertize any newer ones): binutils 2.22.51-1 gcc4 4.5.3-3 gcc4-core 4.5.3-3 gcc4-g++ 4.5.3-3 gcc4-java 4.5.3-3 gdb 7.3.50-2 emacs 23.3-3 emacs-X11 23.3-3 cgf has already stated that this will be fixed in the next release of gdb; see http://cygwin.com/ml/cygwin/2011-10/msg00564.html In the meantime, can't you use gdb 7.3.50-1? If you also have problems with that release, please send detailed instructions for reproducing the problem (starting with emacs -Q). Ken P.S. If you're building your own emacs and using a Cygwin snapshot, you'll need to apply my patch to fix the memory allocation problem that we discussed a few months ago. You can get this by using setup.exe to download the source for emacs-23.3-3. -- 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
setup.exe, dependencies, and 'keep' mode
Hi all, There's a somewhat annoying behavior in setup.exe when installing packages in 'keep' mode: all dependencies selected by things which would have been installed in 'Curr' mode still try to download. Often I can tell that they're spurious and just choose not to install them, but it would get messy if the thing to be installed actually had dependencies... Case in point: downloading gdb-7.3.50-1 requests dependencies ca-certificates-1.78-1 and libgcj11-4.5.3-3 -- neither of which strikes me as a likely candidate, and both of which are highly likely candidates given that I'm not at the latest versions of libgcj or libcurl4... Anyone else seen this behavior? Ryan -- 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: setup.exe, dependencies, and 'keep' mode
On 11/9/2011 5:43 PM, Ryan Johnson wrote: There's a somewhat annoying behavior in setup.exe when installing packages in 'keep' mode: all dependencies selected by things which would have been installed in 'Curr' mode still try to download. Often I can It's a setup.hint bug. While setup.exe does support per-version requires: statements, most setup.hints don't use that, and instead specify global requirements. So, bob uploads the new package foo which now requires libbar, and he simply modifies the (global) requirements to add libbar. When you try to keep the old foo, setup.exe still notices that the requirements now include libbar, and you don't have it installed, so... -- Chuck -- 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: gdb broken inside emacs (again? still?)
On 09/11/2011 5:32 PM, Ken Brown wrote: On 11/9/2011 4:44 PM, Ryan Johnson wrote: Debugging anything within emacs is thus completely impossible at this time. cgf has already stated that this will be fixed in the next release of gdb; see http://cygwin.com/ml/cygwin/2011-10/msg00564.html Sorry, must have missed that one. Thanks for pointing me at it. In the meantime, can't you use gdb 7.3.50-1? If you also have problems with that release, please send detailed instructions for reproducing the problem (starting with emacs -Q). No luck: $ cygcheck -cd | grep gdb gdb 7.3.50-1 libgdbm41.8.3-20 $ emacs -Q -nw M-x gdb Run gdb (like this): gdb (gdb) quit ... long time passes... C-c C-cQuit (gdb) ^D Debugger finished P.S. If you're building your own emacs and using a Cygwin snapshot, you'll need to apply my patch to fix the memory allocation problem that we discussed a few months ago. You can get this by using setup.exe to download the source for emacs-23.3-3. That would explain why emacs-bootstrap.exe keeps hanging. I'll try building from the patched source tree and see what happens. Ryan -- 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
Cygwin toolchain now available for Fedora 16
The Cygwin cross-compiler toolchain is now available for Fedora 16 i686 and x86_64. The fedora-cygwin-release-3-1.noarch.rpm package, available from multiple locations, will enable the Fedora Cygwin repos for Fedora 14 and up on either arch. Yaakov Cygwin Ports -- 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: gdb broken inside emacs (again? still?)
On 09/11/2011 5:32 PM, Ken Brown wrote: On 11/9/2011 4:44 PM, Ryan Johnson wrote: Running just `gdb' from emacs allows it to initialize, but attempts to load a file or indeed perform any command hang until a double-^C cancels the attempt (reporting C-c C-cquit). Ironically, even `quit' hangs, so you have to use ^D to exit. Debugging anything within emacs is thus completely impossible at this time. cgf has already stated that this will be fixed in the next release of gdb; see http://cygwin.com/ml/cygwin/2011-10/msg00564.html Hmm. After dwelling longer on the above post chain... I think cgf was only talking about fixing the seg fault. Is this freezing somehow related? I didn't think it was. P.S. If you're building your own emacs and using a Cygwin snapshot, you'll need to apply my patch to fix the memory allocation problem that we discussed a few months ago. You can get this by using setup.exe to download the source for emacs-23.3-3. Built, but unfortunately no improvement in behavior by gdb. Is there some possibility those cygwin-specific patches somehow are tied up in this? The last time this came up a home-built emacs worked with gdb-7.3.50-1. As others have reported, gud-gdb can load and run binaries, but then emacs doesn't sync up its output with source files any more... BTW, I don't know if this has anything to do with anything, but `strace gdb' from the command prompt or inside emacs reports an infinite stream of seg faults: 25 1231358 [main] gdb 4112 __set_errno: void san::leave():277 val 14 --- Process 4112, exception C005 at 6111AE63 71 1231429 [main] gdb 4112 exception::handle: In cygwin_except_handler exc 0xC005 at 0x6111AE63 sp 0x149C8F4 67 1231496 [main] gdb 4112 exception::handle: In cygwin_except_handler sig 11 at 0x6111AE63 82 1231578 [main] gdb 4112 exception::handle: In cygwin_except_handler calling 0x0 29 1231607 [main] gdb 4112 __set_errno: void san::leave():277 val 14 --- Process 4112, exception C005 at 6111AE63 75 1231682 [main] gdb 4112 exception::handle: In cygwin_except_handler exc 0xC005 at 0x6111AE63 sp 0x149C8F4 28 1231710 [main] gdb 4112 exception::handle: In cygwin_except_handler sig 11 at 0x6111AE63 28 1231738 [main] gdb 4112 exception::handle: In cygwin_except_handler calling 0x0 ^C kills the program, but attempting to type any other character hangs gdb, strace, and the terminal for good measure. Is gdb just known-unfriendly to strace? Ryan -- 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
PHP (was: Re: Pass windows-style paths to the interpreter from the shebang line ?)
On Wed, 2011-11-09 at 16:50 +0100, Corinna Vinschen wrote: On Nov 9 09:45, Jeremy Bopp wrote: On 11/9/2011 09:29, Corinna Vinschen wrote: I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. [...] I should have known that. Sorry Yaakov. No problem, I've only been shipping it for four years now[1]. :-) It's funny that this came up now. I was just working on lining up the new deps for Qt4, when I realized that the new QtSql deps and those I would need to ITP php are practically the same. I was actually debating ITPing it and ITAing apache2 from Ports, if there is interest. Yaakov [1] http://cygwinports.blogspot.com/2007/10/php-on-cygwin.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: Why 'script' utility require SHELL (and work fine under Linux)?
Greetings, Cyrille Lefevre! Would defining $SHELL at a system level solve your issue? -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.11.2011, 05:04 Sorry for my terrible english... -- 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: ssh public key authentication problem using curl
Greetings, carolus! You didn't supplied a username to the remote host at all. Quite predictable, you got a name mismatch... Thanks. That was the clue. The following all work, connecting to my cygwin home directory on the server: ssh dell03 sftp dell03 lftp sftp://dell03 but curl requires a more explicit syntax: curl sftp://cdr@dell03 I had tried curl -u cdr, but that asks for a password. Since I want to use curl in a script, I did not want to have to enter a password. I did not think of trying a different syntax until reading your suggestion. Many tools take your $USER as login name to remote host by default. Which is a rather wild guess, in general, but often works... locally. -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.11.2011, 05:06 Sorry for my terrible english... -- 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: Pass windows-style paths to the interpreter from the shebang line ?
Greetings, Jeremy Bopp! Does php not have an equivalent of the -S option (search the PATH for the named script) that perl and ruby have? I've used that many times to deal with cases where people have Windows-native builds of those tools instead of the Cygwin ones for whatever reason. It does have a similar functionality. But this is not the real problem. -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.11.2011, 05:28 Sorry for my terrible english... -- 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: Pass windows-style paths to the interpreter from the shebang line ?
Greetings, Timothy Madden! I would like to write a php script to run from my cygwin command line. I have the php CLI executable (php.exe) in PATH and I use #!/bin/env php as the first line of the .php script, and make it executable. Dearly use Windows native version of PHP And here's a simple command file to register your PHP as script interpreter for both simple execution and windows scripting host jobs. @echo off if !%~dpnx1 == ! (echo Usage: %~dp0 path_to_php-cli.exe exit) if not exist %~dpnx1 (echo Invalid path to PHP interpreter exit) ftype PHPScript=%~dpnx1 -f %%1 -- %%* assoc .php=PHPScript regsvr32 %~dp1\php5activescript.dll If you still insist on using shebang, just use #! php without any additions. That assuming you have PHP in your application search path. Which is not limited to $PATH, so to speak. -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.11.2011, 05:19 Sorry for my terrible english... -- 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
[ANNOUNCEMENT] Updated: {libmng/libmng1/libmng-devel/libmng-contrib}-1.0.10-2: A library of functions for manipulating MNG format files
Hi New versions of 'libmng/libmng1/libmng-devel/libmng-contrib' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] Updated: {libsmi/libsmi2/libsmi-devel}-0.4.8-2: A library that allows management applications to access SMI MIB module definitions
Hi New versions of 'libsmi/libsmi2/libsmi-devel' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: gdb broken inside emacs (again? still?)
On 11/9/2011 6:08 PM, Ryan Johnson wrote: On 09/11/2011 5:32 PM, Ken Brown wrote: On 11/9/2011 4:44 PM, Ryan Johnson wrote: Debugging anything within emacs is thus completely impossible at this time. cgf has already stated that this will be fixed in the next release of gdb; see http://cygwin.com/ml/cygwin/2011-10/msg00564.html Sorry, must have missed that one. Thanks for pointing me at it. In the meantime, can't you use gdb 7.3.50-1? If you also have problems with that release, please send detailed instructions for reproducing the problem (starting with emacs -Q). No luck: $ cygcheck -cd | grep gdb gdb 7.3.50-1 libgdbm4 1.8.3-20 $ emacs -Q -nw M-x gdb Run gdb (like this): gdb ^ That's your problem. You've deleted `--annotate=3' from the prompt emacs gave you. emacs-23 needs that to be there. M-x gdb works fine for me like that, using both gdb 7.3.50-1 and 7.3.50-3 (which is now available). I tested with Cygwin 1.7.9 as well as with the latest snapshot. Ken -- 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: gdb broken inside emacs (again? still?)
On 09/11/2011 9:37 PM, Ken Brown wrote: On 11/9/2011 6:08 PM, Ryan Johnson wrote: On 09/11/2011 5:32 PM, Ken Brown wrote: In the meantime, can't you use gdb 7.3.50-1? If you also have problems with that release, please send detailed instructions for reproducing the problem (starting with emacs -Q). No luck: $ cygcheck -cd | grep gdb gdb 7.3.50-1 libgdbm4 1.8.3-20 $ emacs -Q -nw M-x gdb Run gdb (like this): gdb ^ That's your problem. You've deleted `--annotate=3' from the prompt emacs gave you. emacs-23 needs that to be there. M-x gdb works fine for me like that, using both gdb 7.3.50-1 and 7.3.50-3 (which is now available). I tested with Cygwin 1.7.9 as well as with the latest snapshot. !! That was it. Thanks a lot, and sorry for the bother. Ryan -- 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: gcj exception compiling
On 06/11/2011 01:28, Yaakov (Cygwin/X) wrote: Install libgcj11. (P.S. Dave Korn: I took the liberty of fixing this on sourceware.) Thanks Yaakov. (That's now three things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4. I need a notebook) cheers, DaveK -- 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: Possible Bug (clarification) in Cygwin 1.7.5 -- findfirstfile (and findnextfile) yeild bad cfilename when file names have special characters. Works in cygwin 1.5, fails in 1.7
Many thanks to Charles and Corinna for the help. I have modified the code to use the POSIX functions. I still have one problem I cannot seem to conquer. I need to be able to read and write the (yes, I know it's evil) archive bit. Unless there is a POSIX function (which I seriously doubt) for these items, I am locked into the windows APIs. I have read and re-read the Cygwin documentation on internationalization at least 6 times and I cannot figure out what I need to do to get this to work. I have tried numerous combinations of environment variables and locale settings in the code, but none of them work. The windows API fails to find the file specified. I just want US English that can handle the extended character set to the windows APIs. In this case, let's use the example of the copyright symbol (the small c with a circle around it). What needs to be set in the environment, and what needs to be set in the C code to handle these characters correctly? Your help and assistance is GREATLY appreciated. Leon Leon Vanderploeg Cell 303-877-9654 On Nov 3 17:56, Charles Wilson wrote: On 11/3/2011 4:48 PM, Leon Vanderploeg wrote: With cygwin 1.7.5, cFileName with a special characters such as ñ (n with tidle above it) fail be properly extracted from a WIN32_FIND_DATA structure with findFirstFile (or findNextFile). To set up a simple test scenario, I created a file in C:\Testing named Mañana.docx. I compiled the code at the end of this message on Cygwin 1.7.9 with GCC version 3.4.4 on Server 2008 32 bit system. On this system (and on a Windows 7 32 bit machine), it returns: a) Why are you using native Win32 APIs in a cygwin program? You should be using the POSIX interfaces instead -- see /usr/include/dirent.h. DIR *opendir (const char *); DIR *fdopendir (int); struct dirent *readdir (DIR *); int readdir_r (DIR *, struct dirent *, struct dirent **); void rewinddir (DIR *); int closedir (DIR *); ACK++ b) What you observe is an artifact of cygwin-1.7's new *support* for i18n. In cygwin-1.5, it just didn't care and passed all the bytes back exactly as found without transliteration. In 1.7, it (correctly) transcodes strings into the current locale -- and your current locale does not appear to support ñ -- or, at least, you haven't told cygwin to use the correct one. (I'm probably thoroughly botching this explanation, but the point is, Just a bit. What you have to keep in mind is that Windows stores all object names, including filenames, as UTF-16 strings, UNICODE in Windows terminology. When you use the ANSI Win32 API as in this example, then the UTF-16 names are converted to the currently defined ANSI charset on output, for instance codepage 1252 for Western Europe languages. Cygwin 1.5 either used the ANSI API, or it converted strings from UTF-16 to the current Windows ANSI charset or vice versa. Cygwin 1.7 doesn't use the ANSI API anymore, rather it uses UNICODE to talk to Windows only, and the multibyte charset is defined through the environment(*) as defined in POSIX. UTF-8 is the default now. you need to check your LC_* and LANG env vars, and maybe call setlocale(LC_ALL, ) in your application.) And even than the code won't work. If you don't define UNICODE, FindFirstFile/FindNextFile will use the ANSI versions of this API, FindFirstFileA/FindNextFileA. If you didn't set your LANG/LC_CTYPE/LC_ALL variables to use your current Windows ANSI charset *and* called setlocale, Cygwin will use UTF-8 by default. Therefore, the character ñ will have another multibyte encoding, 0xc3 0xb1, rather than, say, 0xf1 in Windows codepage 1252. To avoid this problem, you can use the UNICODE API FindFirstFileW/ FindNextFileW and convert the filename the current multibyte charset via wcstombs and friends. However, as Chuck has pointed out, the obviously right thing to do is to use the POSIX API opendir/readdir/closedir instead. Corinna -- 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: What updates done after October 3 may affect gfortran built binaries?
On 09/11/2011 13:31, Edvardsen Kåre wrote: In order to replicate my build you need to install latest version of the grib_api library (http://www.ecmwf.int/products/data/software/download/grib_api.html) and istall it with jasper What is jasper? Wikipedia lists four entirely different open source projects by that name! Also, how big is your build directory? If of a manageable size, please zip/tar it up and send me a copy off-list; if it's huge, please just send me a copy of the broken executable (also off-list). cheers, DaveK -- 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: Missing cygmpfr-4.dll
On 01/11/2011 20:05, Thomas Daniel wrote: How do I install the libmpfr4 library? Sorry for the trouble, I found it, installed it and all is fine. It would be nice if it were picked up automatically though. Sorry about that; it is indeed supposed to be automatic, but I messed up when I was packaging the last release of GCC. I've fixed the dependencies on cygwin.com now, so the problem should not arise again. cheers, DaveK -- 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: gcj exception compiling
On 10/11/2011 05:17, Dave Korn wrote: On 06/11/2011 01:28, Yaakov (Cygwin/X) wrote: Install libgcj11. (P.S. Dave Korn: I took the liberty of fixing this on sourceware.) Thanks Yaakov. (That's now three things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4. I need a notebook) *Four* things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4, and restore the missing download_ecj.sh script. I wasn't expecting some kind of a Spanish Inquisition .. cheers, DaveK -- 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: gcj exception compiling
On Thu, 2011-11-10 at 05:29 +, Dave Korn wrote: *Four* things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4, and restore the missing download_ecj.sh script. I wasn't expecting some kind of a Spanish Inquisition .. I keep all the build files for a package in a persistent, version-controlled directory (one dir per source package) so that whenever I come to change or update a package, the files are all ready to go. Fixes like these could be made now to your local copy so that you don't forget when you next update the package. As for ecj, I'm afraid that was my fault; I have a package in Ports as part of the Java stack, so my gcc4-java worked OOTB. Yaakov -- 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: gcj exception compiling
On Thu, Nov 10, 2011 at 05:29:14AM +, Dave Korn wrote: On 10/11/2011 05:17, Dave Korn wrote: On 06/11/2011 01:28, Yaakov (Cygwin/X) wrote: Install libgcj11. (P.S. Dave Korn: I took the liberty of fixing this on sourceware.) Thanks Yaakov. (That's now three things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4. I need a notebook) *Four* things to remember for next build: remove ecj dependency, change libgcj9 - 11, add missing libmpfr4, and restore the missing download_ecj.sh script. I wasn't expecting some kind of a Spanish Inquisition .. That's understandable. Nobody really does. cgf -- 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: Copy, paste and deleting characters in the openssh screen.
On 9 November 2011 16:31, Jeremy Bopp wrote: On 11/9/2011 08:38, gabier wrote: Hi, I am experiencing daily frustration because I do not know how to get the following features to my fingertips while controlling my Freenas/FreeBSD server from my openssh console on a remote Windows computer. 1) copy from windows document or browser and paste in the openssh console 2) copy from the openssh console and paste either on another line of the console or on a windows document While you can get this to work with the default Cygwin terminal (cmd.exe), pedantry Cmd.exe and the console window (as used by Cygwin) are separate things. Windows automatically creates a console window when a console program is invoked from Explorer. Cmd.exe is just one such console program; Cygwin's bash.exe is another. /pedantry you would be better off installing the mintty package and using that for your terminal instead. You can configure it to behave like a typical xterm with respect to copying and pasting, so you may find that much more familiar. To copy and paste from a regular Windows program, highlight the text and press CRTL-C to copy as usual. Then go to your mintty window and paste using the method you configured for it in its configuration dialog. I think pressing SHIFT-INS should work by default, but there are other options available, including middle clicking (not the default IIRC). Paste by middle-click is enabled by default too. To copy and paste from the mintty window, highlight the text and then copy using the method you configured for mintty. I have my mintty configured to copy automatically when text is highlighted, but that's not the default as I recall. It wasn't on by default originally, but it has been for a little while now. Other ways include the Copy command in the right-click menu and its Ctrl+Ins shortcut. Once the text is copied, paste into a Windows program as usual with CRTL-V or paste back into the mintty window as discussed previously. Note besides: Ctrl+Ins for copy and Shift+Ins for paste are standard Windows shortcuts too. Ctrl+C and Ctrl+V can't reasonably be used as shortcuts by a terminal because they're used by many terminal applications. However, there's an option on the Keys page of mintty's options dialog that allows Ctrl+Shift+C and Ctrl+Shift+V to be used for copy/paste. 3) correct my openssh commands by deleting characters with the backwards stroke. Sometimes it works, sometimes not, it seems to depend on the type of login! The local user (Cygwin) seems to work, the root user on the freebsd server seems also to work, but another user on the freebsd server does not work : if I hit the backward stroke it prints a triangle (meaning I suppose unknown character) and there is no way to correct this but to send the wrong command and retype the whole command. With long commands it can be very frustrating. What sort of server is it? This may get corrected automatically by using mintty as your terminal, but it's really not a Cygwin-specific issue. I've had similar problems in the past and was able to work around them by pressing either CTRL-H or CTRL-BACKSPACE. My vague understanding of the problem is that the terminal sends a particular character in response to the backspace key, which is configurable in many terminals. Yep. Ye olde and ever-exciting ^? vs ^H issue. Mintty is one such terminal, but the cmd terminal is not. Actually the Cygwin console's backspace character can be changed too, but only through a control sequence: For ^H: echo -ne '\e[?67h' For ^?: echo -ne '\e[?67l' Both the console and mintty use ^? by default. Linux terminals also usually default to ^?, but BSDs might well default to ^H. Without the ability to change the character sent by the terminal program, you would need to be able to configure the remote applications to do the right thing with whatever character *is* sent, but that can be a tall order due to the different ways you may have to configure each application. You could try the following command on the remote system to tell it that the backspace key sends ^?: stty erase '^?' (Many ssh servers set that automatically in accordance with the setting on the client side, but apparently some don't.) Andy -- 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
Updated: {libmng/libmng1/libmng-devel/libmng-contrib}-1.0.10-2: A library of functions for manipulating MNG format files
Hi New versions of 'libmng/libmng1/libmng-devel/libmng-contrib' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: {libsmi/libsmi2/libsmi-devel}-0.4.8-2: A library that allows management applications to access SMI MIB module definitions
Hi New versions of 'libsmi/libsmi2/libsmi-devel' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
