Re: [RFU] rsync-3.0.4-1
I'm responding to the message sent on 19 Oct 2008, at around 11:26 UTC, by Lapo Luchini lapo ~at~ OBSCURED dot NUL, who wrote Subject: [RFU] rsync-3.0.4-1 http://lapo.it/cygwin/nano/nano-2.0.9-1-src.tar.bz2 http://lapo.it/cygwin/nano/nano-2.0.9-1-src.tar.bz2 http://lapo.it/cygwin/nano/nano-2.0.9-1.tar.bz2 http://lapo.it/cygwin/nano/setup.hint Changed setup.hint (removed libiconv2, used thru libintl8): sdesc: A pico clone text editor with extensions ldesc: nano - A text editor designed as a clone of pico, but rewritten from scratch to be faster and smaller while having greater functionality category: Editors requires: cygwin libncurses8 libintl8 PS: I did *not* change it to use PCRE library as suggested on cygwin@, as they're not 1:1 compatible (some of the default context-coloring script fails with PCRE) and, being also slower as pointed out on the same ML, I'm not yet convinced it's the Right Thing To Do (c) I think you missed an edit on this sending, Lapo ;-). -- Blame it on Caradhras the Cruel.
Re: please add a find-the-fastest-mirror-automatically feature to setup.exe
On Fri, 23 May 2008 12:23:13 -0400 Chris Sutcliffe [EMAIL PROTECTED] wrote: Setup.exe is a great tool, but could you please add a find-the-fastest-mirror-automatically feature? That would require making a connection attempt to every entry in setup's list, which would be rather counter-productive I would think. Yes, it would (and annoying, etc...). However, I can envision a compromise solution in which Setup.exe looks for a file, a la unix user rc files, and if found reads the address of the preferred host to use from that file. Caching the result of a one-time burst of pings, in other words. Soren A -- All unaccompanied children will be given espresso and a free kitten. -- Find out how you can get spam free email. http://www.bluebottle.com/tag/3
Re: Package Maintainer List
On Wed, 12 Dec 2007 Corinna Vinschen wrote:
As requested by Lapo, here's the latest Package Maintainer List.
Feel free to correct me if I got something wrong or missed some
change.
The original list I'm maintaining is just ordered alphabetically,
so it doesn't have this neat sections for orphaned and maintained
packages. However, since it's always supposed to represent the latest
state, I decided to make it publically available:
http://cygwin.de/htdocs/cygwin-pkg-maint
http://cygwin.com/cygwin-pkg-maint
But now the famous list of packages.
{snip}
distcc (Harold L Hunt II)
My intention conveyed in
http://cygwin.com/ml/cygwin-apps/2007-08/msg00104.html still holds.
There's been no upstream newer release of distcc in the interim -- I am
carefully monitoring the distcc list. There *is* a recently posted bug
report and patch which hasn't been acknowledged yet by the distcc
upstream maintainer (author). It would seem that maybe he's a bit busy
right now. Speaking of which ...
Can i respectfully point out that this time of year, depending on what
culture and society we live in, is an extremely hectic one -- maybe the
most pressured of the entire calendar. Some people may not be aware of
this, but in North America we have a quaint custom called Christmas
in which we often have special obligation to arrange togetherness with
family, plan gifts to give to others, etc. People not of Christian
faith (as i am not) are still part of the society and in my case, do
have such obligations, or similar ones existing around holidays like
Chaunukha or New Years. Making announcements to solicit maintainers
for the orphaned packages right at this moment may result in a far
narrower catch of potentially-interested persons than if it had
waited until after the holidays were over ...
I'd still like to be maintainer of distcc. I'd like to have a little
more time to see what's up with upstream packages and to do my holiday
thing. Unless there are pending bug reports against cygwin's distcc
package, or an upstream maintainence release has been made which mifgt
affect cygwin, i don't feel a rush for adoption-action (creation of the
new release) is warrented in this case (and maybe others like it).
Regards,
Soren Andersen
--
All unaccompanied children will be given espresso and a free kitten.
--
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5
Re: [ITA] distcc 2.18.3-2 -- A fast, free, distributed C/C++ compiler
On Thu, 13 Dec 2007 00:36:19 +0200 Jari Aalto (Cygwin-bug#20070808T0434) [EMAIL PROTECTED] wrote: See previous ITA threads: http://cygwin.com/ml/cygwin-apps/2007-08/msg00037.html http://cygwin.com/ml/cygwin-apps/2007-08/msg00104.html Please see my reply to (what I think is) cygwin-apps message 22085 (message id [EMAIL PROTECTED]) Subject: Package Maintainer List. Thanks. -- All unaccompanied children will be given espresso and a free kitten. -- Free pop3 email with a spam filter. http://www.bluebottle.com/tag/5
Re: gcc 4.x for Cygwin?
On Tue, 27 Nov 2007 18:38:15 +0100 FWIW, my 2 cents: Corinna Vinschen wrote: As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? I am also inclined towards preferring option 2. In my case, I have no interest in the ada or java compiler components, and as yet use cygwin for GUI work very little or nil. From what I understand of the issues, dwarf2 exception handling is the far cleaner approach, contrasted with sjlj. The jump from release 3 to release 4 GCC seems like the right time to make a switch that might confound some user's uninformed expectations (i.e. What? You mean I cannot just switch from gcc-3.x.x to gcc-4.x.x on Cygwin without knowing about ramifications?). If the switch isn't made at the 3-4 transition boundary it becomes that much less easily remembered and communicated to users as they come along. I'm also in agreement with the notion expressed by Brian Dessent (in [EMAIL PROTECTED]): [...] switch to DW2 exception handling as default for all of Cygwin and then think about providing a fallback/parallel installation sjlj package for anyone doing Win32 GUI stuff. Not that I suggest it would be a trivial effort for someone to support such a parallel package; but if someone was *willing* to do so it seems like a solution that would provide options valuable to some Cygwin users. Regards. -- All unaccompanied children will be given espresso and a free kitten. -- Find out how you can get spam free email. http://www.bluebottle.com/tag/3
[ITA] distcc (ready soon)
Greetings all. Respectful salutations to Jari Aalto with sincere acknowledgement of his work in starting to adopt distcc (2.18.3) from Harold Hunt. If its ok, I'd like to maintain this package instead. Chris Faylor / cgf asked me a few weeks ago if I'd like to do so, in the context of a discussion of distcc on the unofficial Freenode #cygwin channel. I had to reply at that time, that I would ponder and research it. It seems like something I'd like to do, I've decided. I have been using distcc for several months on Cygwin and GNU/Linux. I'm building a heterogenous distcc cluster bit by bit, populating machines with cross-compilers, etc. Since I've been a Cygwin user for many years I am not new to Cygwin, but I am new to package-maintenance on Cygwin. I'll thank all in advance for any support you can extend to me in this regard. The last week has been intensely busy with local (offline) obligations to fulfill, so I have not yet been able to set up a Net location for download of the source kit for distcc-2.18-3. I have, however, built the software from source (just pulled the source from the Setup.exe, as Cygwin distcc is still abreast with upstream's last release). I'm going to use the older traditional script build that Harold Hunt used, for the time being. So to cut to the chase: in a short while distcc-2.18.3-[2?] packaged Cygwin binary should be available for testing. I also intend to write some Cygwin-specific documentation about running distccd (the daemon) on Cygwin, especially as a Windows service. I found, after extensive trial and error, a set of flags to set distccd up with cygrunsrv, that seems to provoke no error messages from Windows: (As an Administrator on the machine): | $ cygrunsrv -I distcc -d DISTCC -p /usr/bin/distccd |-a '--log-level info --no-detach --allow example1 dotted-quad/24 \ | --allow example2 dotted-quad/24' -n -o | $ cygrunsrv -S distcc The command $cygrunsrv -V -Q distcc outputs: Service : distcc Display name: DISTCC Current State : Running Controls Accepted : Stop, Shutdown Command : /usr/bin/distccd --log-level info --no-detach \ --allow example1 dotted-quad/24 \ --allow example2 dotted-quad/24 stdin path : /dev/null stdout path : /var/log/distcc.log stderr path : /var/log/distcc.log Special flags : --neverexits --shutdown Process Type: Own Process Startup : Automatic Account : LocalSystem That seems to indicate a lack of even a fake error condition (which can happen, as per the cygrunsrv documentation, when a typical Unix daemon is run as a service under Cygwin). The key was obviously omitting the --daemon flag to distcc. HTH. Soren Andersen Referenced list messages: From: Jari Aalto [EMAIL PROTECTED] Subject: [ITA] distcc 2.18.3 - A fast, free, distributed C/C++ compiler Date: Wed, 08 Aug 2007 15:54:55 +0300 (08:54 EDT) and From: Christopher Faylor [EMAIL PROTECTED] Subject: Re: [ITA] distcc 2.18.3 - A fast, free, distributed C/C++ compiler Date: Wed, 8 Aug 2007 17:13:14 -0400 -- All unaccompanied children will be given espresso and a free kitten. -- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2
Re: example needed pls: `cygpath -c HANDLE'
On Sun, Jun 29, 2003 at 12:17:01PM +0200, Gerrit P. Haase wrote:
Hallo Soren,
you also wrote:
I am trying to finish a test script that uses ActivePerl to call `cygpath`
{... stuff ...}
open(CTH, '-|', C:/cygwin/bin/cygpath $MS_path_filename)
or die Could not open() call to 'cygpath', what is up?;
$cygstyle_path = CTH;
chomp $cygstyle_path;
{... stuff ...}
#!/bin/perl
$MS_path_filename = 'H:\bin';
$MS_path_filename = quotemeta($MS_path_filename);
open(CTH, '-|', H:/bin/cygpath $MS_path_filename)
or die Could not open() call to 'cygpath', what is up?;
$cygstyle_path = CTH;
chomp $cygstyle_path;
print $cygstyle_path\n;
# SCRIPT_END
{Gerrit's output}
$ /bin/soren_problem.pl
/bin
What is the problem?
See my original message please! What I was asking for was an explanation
of the cygpath flag -c HANDLE.
I know the code above works, it ran for me too. First of all you aren't
reproducing the conditions of the test: NOT CygPerl, but Win32Perl (AS
Perl); secondly NOT on the console/terminal commandline but in a WSH
script (the code is executed when the hooks built in to WSH which know
how to call AS Perl, do so); and lastly I am not asking for readers to
reproduce the test (because it might be onerous to do so, because
they've never used WSH or don't have AS Perl installed, but if someone
does have a system which meets those criteria I'd be mightily obliged if
they would try).
I am just trying to understand what it might be about cygpath that it
cannot output anything under *these* conditions. Or find out whatever
there is to find out.
Thanks Gerrit!
Soren A.
--
See my OpenPGP key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: example needed pls: `cygpath -c HANDLE'
Hi!
Regarding reply by Brian Dessent [EMAIL PROTECTED] wrote around 28 Jun 2003
Here's a little thing I cooked up that I find very useful, I call it
dodos. It lets you run any DOS/Windows program and call it with unix
arguments. For example, you could type dodos notepad /etc/aliases
or dodos notepad /etc/hosts.* and you'd get what you expect.
#!/usr/bin/perl -w
my @newargs = $ARGV[0];
foreach my $arg (@ARGV[1..$#ARGV]) {
my $foo = quotemeta($arg);
$foo = `cygpath -wsa $foo 2/dev/null`;
chomp $foo;
push @newargs, $foo;
}
exec @newargs;
(I replied:)
Heh. Looks like a candidate for a Schwartzian Transform, or the Orcish
Manuever, or something :-/. But good anyway. I'll add it to my toolset.
Well, brain misfire apparently happened; the ST and Orcish maneuver both
pertain to *sorts*, and there's no sorting going on here. What I was
thinking was that there ought to be a use for Perl's map() here, and
there is (of COURSE, because it's Perl so TMTOWTDI!). Nevertheless
although I can come up with a more highly obfuscated and terse way to do
this, it doesn't reduce down very much due to the external system call
to `cygpath'.
S, risking that I'll just publicly expose *another* brain misfire,
I'll venture to offer some thinking I did about this. No warrenties
whatsoever, yaddayaddayadda.
Since my earlier reply I've done some serious playing around with this
code and discovered it suffers from severe limitations. On WindowsXP I
found almost no basic Windows tools that take just a list of filenames
characteristically, as args; most native tools take just one arg and a
bunch of flags, which usually look like: /X where X is one or more
characters. I don't think your code is going to handle that too well!
In short although I see what you are doing, I think it's too simple for
many cases and its lack of robustness makes it only marginally useful to
me (IMHO). If you could post some typical examples of how you use it, to
refute me, I'd be pleased.
One variation of your code I came up with looks like this, and
demonstrates the initial ~ 50% reduction in numbers of lines, but
handles a little more (and so num lines swelled back up):
-8 snip here
#!/usr/bin/perl
# dofn4dos - translate arguments to run a WinDOS application
# from the Cygwin shell. Use ^ as a special (disposed-of)
# escape char mechanism for flags like /YO.
exec
$ARGV[0],
map { if(s/^\^//) {
$_;
} elsif(/^\-/) {
$_;
} else {
$_ = quotemeta($_);
chomp($_ = `cygpath -wsa $_ 2/dev/null`);
$_;
}
}
@ARGV[1 .. $#ARGV]
;
__END__
-8 snip here
That's both pretty terse (perl-ish) and yet I think most people can see
what's going on; and also it handles a couple of common idioms for
passing flags in a command line: the initial-hyphen idiom typical of
*nix/POSIX tools, and the worrisome Win32/DOS idiom / (regular/forward
initial slash, which looks like a fqfn under *nix). Of course you have
to remember to put an eatable caret (GET IT!!??!!) in front of such a
flag arg to protect it from cygpath. When Perl is done the caret is
gone and `cygpath' has kept its paws off your flag.
--
See my OpenPGP key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: example needed pls: `cygpath -c HANDLE'
On Sat, Jun 28, 2003 at 03:09:15PM -0700, Brian Dessent wrote:
I was playing around with this because it seems like a handy idea.
I use Cywin perl, but the differences shouldn't be very great. Anyway,
I came up with the following oneliner that does what you mention above
(passed %1 as a Windows filename, it copies the Cygwin version to the
clipboard)
c:\cygwin\bin\perl.exe -MWin32::Clipboard -e my $f=quotemeta('%1'); chomp (my
$c=qx!cygpath -u $f!); Win32::Clipboard($c);
How on earth did you get Win32::Clipboard (or Win32::anything) to run
under CygPerl, Brian? The Win32:: namespace code is incomatible with
cygwinperl, any module using such cannot be built to cygwinperl AFAIK.
Soren A.
--
See my OpenPGP key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: example needed pls: `cygpath -c HANDLE'
On Sat, Jun 28, 2003 at 10:45:26PM -0400, Igor Pechtchanski wrote: Umm, guys, aren't we getting carried away here? I mean, perl is a great tool, but wouldn't something simpler, like c:\cygwin\bin\bash -c echo -n `/bin/cygpath -u '%1'` /dev/clipboard suffice? If that command string could somehow be made to be the action that takes place when the user right/context/alternate-clicks on a filename in Win Explorer, then yes, it would address the need. Do you know how? The mere use of the shell redirection to the POSIX (NOT Win32!!) file /dev/clipboard makes it seem highly unlikely that you were aware of the original statements / descriptions I made; I cannot see how these would apply outside the Cygwin BASH shell (textmode terminal) environment. Regards, Soren A. -- See my OpenPGP key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ProFTPd usable on WinXP-HE, questionable to me
On Mon, Jun 23, 2003 at 02:13:31PM -0400, Jason Tishler wrote: s/Tischler/Tishler/ Sorry ;-) LocalSystem user. I don't know what OS Jason is talking about as there is no such user LocalSystem on WinXP (yet XP is decended from NT). The built-in Windows LocalSystem account maps to the Cygwin SYSTEM user. So in the /etc/proftpd.conf file I have lines like: User SYSTEM Group Administrators The above should be correct. but when I try to run proftpd, it refuses to start because it won't change user context. The user I run Cygwin as apparently doesn't have sufficient perms to change user context like this. Did you install proftpd as a NT service via cygrunsrv as indicated in the README? Yes. In brief, I did. Followed the instructions to the letter. Then when it didn't work, i wanted to run in in non-detached (undaemon-ized) mode so that I could try to understand where it was failing. Nothing i tried got it to work: neither doing it the usual way (starting it as an NT service via cygrunsrv) nor trying to watch it run stand-alone. http://www.tishler.net/jason/software/proftpd/proftpd-1.2.9rc1.README I don't know how to add such rights to the account: the user IS (*IS* *IS* *IS*) an Administrator on the local system (was created that way). See my next post. Can anyone loan me a clue about what can be done to fix this, i.e. give my user account sufficient perms to run proftpd as SYSTEM? You should be able to run proftpd under SYSTEM on XP Home. However, I do not have access to XP Home so I cannot verify this hypothesis. BTW, can you run other daemons such as inetd or sshd on this box? Not sure, I haven't tried yet. Thanks Soren A. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Inline-0.44 fails test on Cygwinperl 5.8.0 (xpstd article)
Hello Cygwinauts, Perl5-Porters, Ingy, The current release of Inline.pm won't build for me on the latest cygwinperl (Gerrit's most recent release, 5.8.0-3). I tried running 'test' from CPAN's shell and then went into manual analysis mode, produced some output build logs (attached to this message) and found the failure occurs when a .dll file is not produced. I see by checking at http://testers.cpan.org/search?request=distdist=Inline that no Cygwin tester is currently tracking Inline (last Cygwin test was on 0.43). The attached logs are pretty complete and self-evident so I will only briefly try to describe what's happening where: make[1]: Entering directory `/usr/local/build/cpan/build/Inline-0.44/C' /usr/bin/perl.exe -MExtUtils::Command::MM -e test_harness(3, '../blib/lib', '../blib/arch') t/*.t t/00init...1..1 ok 1 ok t/01syntax.1..5 ok 1 ok 2 ok 3 ok 4 ok 5 ok t/02config.1..3 ok 1 ok 2 ok 3 ok t/03typemap1..1 ok 1 ok t/04perlapi1..1 make[2]: Entering directory `/usr/local/build/cpan/build/Inline-0.44/C/_Inline_test/build/_04perlapi_t_3c76' /usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typemap -typemap /usr/local/build/cpan/build/Inline-0.44/C/t/typemap _04perlapi_t_3c76.xs _04perlapi_t_3c76.xsc mv _04perlapi_t_3c76.xsc _04perlapi_t_3c76.c gcc -c -I/usr/local/build/cpan/build/Inline-0.44/C/t -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -DVERSION=\0.00\ -DXS_VERSION=\0.00\ -I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE _04perlapi_t_3c76.c Running Mkbootstrap for _04perlapi_t_3c76 () chmod 644 _04perlapi_t_3c76.bs rm -f blib/arch/auto/_04perlapi_t_3c76/_04perlapi_t_3c76.dll LD_RUN_PATH= ld2 -s -L/usr/local/lib _04perlapi_t_3c76.o -o blib/arch/auto/_04perlapi_t_3c76/_04perlapi_t_3c76.dll /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a gcc -shared -o cygperl5_8_0.dll -Wl,--out-implib=lib_04perlapi_t_3c76.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib _04perlapi_t_3c76.o /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a Creating library file: lib_04perlapi_t_3c76.dll.a mv cygperl5_8_0.dll lib_04perlapi_t_3c76.dll.a blib/arch/auto/_04perlapi_t_3c76/ chmod 755 blib/arch/auto/_04perlapi_t_3c76/_04perlapi_t_3c76.dll chmod: getting attributes of `blib/arch/auto/_04perlapi_t_3c76/_04perlapi_t_3c76.dll': No such file or directory make[2]: *** [blib/arch/auto/_04perlapi_t_3c76/_04perlapi_t_3c76.dll] Error 1 make[2]: Leaving directory `/usr/local/build/cpan/build/Inline-0.44/C/_Inline_test/build/_04perlapi_t_3c76' The `chmod' call returns failcode because the file does not exist, and it clearly does not exist because the linking step to create it isn't happening (as best I can tell). Thanks, Soren A. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda Inline_build_diagnosis.tar.gz Description: Binary data Cygwin Package Information Package Version _update-info-dir 00170-1 ash 20020731-1 base-files 1.3-1 base-passwd 1.1-1 bash 2.05b-9 binutils 20030307-1 bzip21.0.2-2 ctags5.5-4 cygrunsrv0.96-1 cygwin 1.3.22-1 diff 1.0-1 diffutils2.8.1-1 fileutils4.1-1 findutils4.1.7-4 gawk 3.1.2-3 gcc 3.2-3 gcc-mingw20020817-5 gdbm 1.8.3-1 grep 2.5-1 groff1.18.1-2 gzip 1.3.3-4 keychain 1.9-1 less 378-1 libbz2_1 1.0.2-2 libdb3.1 3.1.17-2 libgdbm 1.8.0-5 libgdbm-devel1.8.3-1 libgdbm3 1.8.3-1 libiconv21.8-3 libintl1 0.10.40-1 libintl2 0.11.5-1 libncurses5 5.2-1 libncurses6 5.2-8 libncurses7 5.3-1 libpcre 4.1-1 libreadline4 4.1-2 libreadline5 4.3-2 login1.9-5 make 3.80-1 man 1.5j-2 mingw-runtime3.0-1 mktemp 1.4-1 ncurses 5.3-1 openssh 3.6.1p1-2 openssl 0.9.7b-1 openssl096 0.9.6j-1 patch2.5.8-3 patchutils 0.2.22-2 perl 5.8.0-3 pinfo
port query: any fping? cygwin headers
Hey! Hello all. Has anyone ever ported the network tool fping to cygwin? I came across some Google results that seemed to be viable but it appears not (I don't have the complete URL I checked, but it was a site that showed a dir listing under a software project named mon. maybe some of you know what mon is). Anyway, the version of fping found was very old (2.2b1). The source rpm from the above referenced (kind of) site was an rpm and right there it doesn't seem to be a cygwin port. But the url did seem to include cygwin. Anyway I extracted the sources from the rpm file and tried to configure and build. I get a bunch of undefined symbols, like ICMP_ where a lot of things follow ICMP_. I checked headers and looked for any such defines in any header mentioned, found none. I did find that there's a header /usr/include/cygwin/icmp.h that is an empty file. Is this a TODO for Cygwin? Another header under netinet/, /usr/include/netinet/ip_icmp.h, just #include's this empty file. The fact that another header does this with an *empty* file seems decidedly bizarre to me. I'd like to have fping ported to cygwin. I have written a tool that finds the best CPAN mirrors for Perl users/admins to connect to, systematically, and that script calls the external program fping. it's working great on Debian but cannot on cygwin, where fping isn't available. Regards. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sharing hd partition betw Linux and Cygwin
On Tue, Jun 03, 2003 at 09:54:16AM -0700, Shankar Unni wrote: Soren Andersen wrote: Now sharing the drive space between the cvs tool (and cpan, too!) works, I think (haven't actually tried cvs yet but had to work on cpan a few minutes ago, and discovered it was suffering from the same difficulty). I'd be amazed if this all works seamlessly. Nevertheless, remember that CVS on cygwin is only supported with binary-mounted filesystems. If your default cygdrive mount is text (i.e. you installed Cygwin with DOS line endings), be sure to create a fresh binary mount for your CVS repository and use that as your CVSROOT. Thanks for the tip, Shankar. I've always had all my mounts in binmode by default so this shouldn't be an issue. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync and cygwin paths
On Wed, Jun 04, 2003 at 10:33:34AM -0700, Randall R Schulz wrote: However for many purposes it's feasible to write some simple-minded heuristics that make the determination about when and how to apply cygpath. I currently use a BASH script that uses a simple case statement to paper over the Cygwin / Windows interface for invoking the Java 2 SDK tools. The case statement's glob patterns detect whether any given argument is (probably) a file name or PATH-like entity and then applies cygpath as necessary. It can be fooled, of course, but in practice it works fine for me. Gosh, you accomplish that with a mere bash script? I wrote an entire class to handle that ;-). Over-working myself as usual I expect! Ten-dollar solutions to 5-cent problems, that's my motto! Soren A. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Mount table in registry
On Thu, Jun 05, 2003 at 04:39:31PM +0200, Sebastian Miele wrote: Would making a libmount.a (or, better yet, cygmount.dll) be a good idea? Then programs can link against it and be guaranteed that they can read mounts or verify mount locations. I know Cygwin exports getmntent() and the like, but the above would be something that doesn't depend on cygwin1.dll. Setup.exe could then use it as well (although then it'd have to be a static lib). Comments, flames? If the resulting cygmount.dll will be distributed under the LGPL or the X11 license in future versions of cygwin (so that any system with cygwin1.dll installed also has cygmount.dll installed), I would do that and add cygwin-windows path conversion functions which also resolve symlinks. Sebastian I for one am in favor of this proposal. I am not a cygwin guru or a heavy-weight programmer in general, i.e. I haven't hacked on Cygwin itself except indirectly (Filesys::CygwinPaths module, for instance), but I've had enough exposure to cygwin that I feel justified in forming an opinion on this matter. Exposing the cygwin mount stuff via a library that can be linked against, where programmers can know where the code is going to be, seems like a helpful and reasonable thing. I am sure there are other considerations -- there always are (sigh) -- but this sounds like something worth pursuing. One thing that would preserved and enhanced by such a service being available, would be the values of independence and creativity that are a part of what I value so much about my experience of using cygwin. I like that cygwin lets me (empowers me) to fool around with bash scripts and so on, that allow me to look at computing problems in new ways and come up with my own ways of solving them. If I don't like the way that something works by default, I can often find a way to make it work instead, the way I want it to. This is harder to do with M$Windows itself because so much is fixed and arbitrarily limited by the design philosophy (term used in the loosest possible manner) prevelent over M$Windows. I once even hacked on `cygpath' and cooked up an altered version that has defaults that make sense to me, different from what is hardcoded into the standard cygwin release of that tool. Never distributed that, of course. Anyway that's an example of what I mean, where my values and enjoyment are at wrt cygwin. -- See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050 GnuPG public key fingerprint | Only when efforts to reform society have as BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of 310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will they lead us with certainty to a world of lasting peace and true human security. -- Daisaku Ikeda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwinperl tar on Win9x (really tar)
Hello Cygwinauts,
I'd like to report a problem I encountered recently try to run CPAN(.pm)
on Cygwinperl to ... you know what CPAN does.
My system is Win98 and I suspect from absence of reports concerning this
that somehow this isn't affecting people on other-derived M$ Windows
platforms. All of this is vis a vis cygwin on these platforms, of
course.
CPAN fails to be able to make or install modules because the system call
to tar(1) returns an error (generates a SIGSEGV [?] signal) when perl
tries to have tar unroll a module archive. On examination, tar is being
called by perl code in the innards of CPAN.pm, with the old-style flags
(switches) un-prefaced by a hyphen/dash/(-) token, e.g.:
$ tar xvf foo.tar
On testing, the stackdump can be caused by manually passing arguments
(flags, switches) to tar(1) without a hyphen. I myself always habitually
use the modern GNU-style with tar, i.e. $ tar -xvzf foo.tar.gz when I
run `tar' manually or use it in scripts, so this bug never bit me before
CPAN showed it to me.
I can run CPAN by modifying the internal CPAN::Config hash to point
toward this other `tar' program which is really a wrapper script (in
CPAN::Config fully-qualified path spec). This wrapper in turn just calls
real `tar' with flags corrected.
-SNIP-8--CUT HERE-
#!/bin/bash
declare opflags=''
declare -a tar_args=($@)
if [ $# == 1 ] || [[ $0 != *tar ]] || [ NUL${tar_args[0]} == NUL ]
then
echo 12 No args or flags passed to $0, must abort with error!
exit 1
else
opflags=${tar_args[0]}
fi
if [[ $opflags != -* ]] ; then
tar_args[0]=-$opflags
fi
# echo Going to do: exec /bin/tar [EMAIL PROTECTED]
exec /bin/tar [EMAIL PROTECTED]
-SNIP-8--CUT HERE-
Sorry, I don't have the opportunity available to me at present to dig
into winsup/ or tar's source code to try to track this down. I wanted to
get something into the record now in case someone else who might have
more time, gets bitten by this too and wants to try to fix it.
Also, sorry, I am composing this message from Debian GNU/Linux, so I
have not the opportunity to generate a cygcheck.exe output file to
attach to this message. My `tar' was from cygwin release 1.13.25 and
then I reverted to the previous one (whatever that was). Both tar
versions manifested the same segfault.
--
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Updated: vim-6.2-1
Thu, Jun 05, 2003 at 03:15:25PM +0200, Corinna Vinschen wrote:
On Thu, Jun 05, 2003 at 02:44:00PM +0200, Michael Schaap wrote:
The problem is: what GUI?
Exactly.
{...}
Not me ;-) I have no idea what gvim is actually good for.
The non-GUI version runs very nicely inside of xterm or rxvt,
so what? -- just a rethorical question
Ah, this gives me an opportunity to say how great it is that Vim is
packaged for Cygwin, thanks Corinna. Believe it or not I ran cygwin all
these years without its native Vim installed until the other day, when I
got around to updating my rather long-neglected (like:5 months) cygwin
installation on Win9x. On impulse I selected Vim and boy was I happy
when I could just fire it up for some quick rcfile editing work and so
forth.
Now as to the rhetorical question: what is GVim actually good for?
With a tool as fundamentally important to programmer/admins as the text
editor, of course there are reasons to want one thing over another
thing. One thing that is great about GVim is its capability to act as a
server which can receive remote commands. This is surprisingly useful
and allows for a lot of creative computing once one begins to explore
it.
Another thing important to some of us is that the display capabilities
of the GUI version (GVim) of course excel far beyond the limitations
imposed by the console. Aside from different languages (human), fonts
and charsets and kbd mappings being possible, there is the superb GVim
syntax-hilighting capabilities which I am always showing off in source
code posted on my website
(http://home.att.net/~perlspinr/browse_site.html). Even if the syntax
hilighting (or degree thereof) seems like mostly a toy to a given
person, to the next one it can be very significant.
All-in-all I think both Vim and GVim have their place. I use Vim (in the
terminal) about 75% of the time now, because much of my work is
currently little systems-admining type of tasks and I can get the needed
edits done quickest that way. For larger jobs where I might be working
on the same file(s) for hours ... days ... (argh) weeks at a time, I much
prefer to be using GVim where the fonts are better and much more
convenience is available.
--
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
sharing hd partition betw Linux and Cygwin
Hello! Hithere folks.
I have been a temporary defector (so to speak) from Win32-running-cygwin
(bless it's heart) to Debian GNU/Linux (bigger blessings yet). As of the
end of last year no posts from me to cygwin. Missme, Chris? ;-) {decidedly
impish grin}.
Now I am back (no, not a Terminator(TM)-voice impression...) and so I
will send greetings along with a pesky question, and hopefully
sufficiently OT to boot, so that Chris et al will have no doubt that
it's really ME and not some well-behaved imposter.
There's little doubt in my mind that a handful of readers who will
eventually see this, are users of Linux as well as of Cygwin (in fact
TTBOMK this applies to cgf himself) and so I am hoping that something
useful might come out of my asking.
Preface: The Cygwin installation is recently updated and is running on top
of Win98SE (yes, sad).
Why: I want to share a CVS repository (local to my machine / localnet
only) between Cygwin and Linux. I want to be able to do checkout's,
commit's and all that from either OS env and share the same cvs ROOT
area on disk.
What: The entire logical partition is mounted on Linux using a mount
point /linms-common/ and the CVS area is under that
(/linms-common/SOMIANCVSROOT). A parallel arrangement (mountpoint
differing but that's all) exists under Cygwin-cvs. No problems exist (or
have manifested yet) under Cygwin, but under Linux I am having problems
with running CVS commands, and those problems are based on perms.
How (it fails): I cannot get CVS to run because it cannot write any
files to that dir.
I am trying to use the mount(1) options to the entry in my Linux
/etc/fstab uid=NNN,gid=NNN in order to correct for a potential problem
arising from differing users on the two systems. I have uid=[the numeric
UID on Win98-Cygwin] and gid=[my GID under Linux] in hopes that group
access rights are sufficient, but it turns out that they are not. By
default all files (dirs) mounted on this vfat - type filesystem under
Linux `mount' are set with perms rwxr--r-- so group members never have
'write' perms. From what I can tell from the docus for Linux 'mount',
there is no way to change this situation on a mount like
Win9x-vfat-(into)Linux.
Any insights? What does the setting of uid=NNN,gid=NNN actually DO on
linux? Is the target fs supposed to be treated as if those are the uid
and gid of the target fs's owning OS (in which case of course Linux
cannot possibly know about what gids and uids exist on that system), or
are the uid and gid of a user on the Linux system? Is there any harm to
be caused by making the uid= that of who I really am running as on the
Linux system (which, if there's no bad side, seems like it might fix the
problem) Oh, and ... any insights?
Finally, is there anything that I can do on the *Cygwin* side to change
the perms that Linux's `mount' perceives on the target filesystem? I
understand that everything relating to *nix-like perms on Win9x is a
complete kludge since there's no user-id -based access control on such a
lame platform, that has any real meaning or bite. On WinNT-derived MS
platforms it might be a different story.
Best Regards,
Soren Andersen
--
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
CPAN module Filesys::CygwinPaths uploaded today
Hello Cygwinauts,
Experimental perl extension module (platform architecture -specific)
Filesys::CygwinPaths has been uploaded to CPAN within the last few
minutes. Over the next several hours (up to one day at least in some
cases depending on Factors Beyond Our Control(TM)) the file should be
propogating to CPAN mirrors around the world (gulp).
Although the new version just uploaded is release 0.04, there are no
changes to the API or functionality of the module itself. This version
bump is necessitated by the need to increment a release on CPAN, the
need to re-upload in turn is necessitated by the presence in the
previous release (0.03) of a build-bug that probably prevented
everyone using CPAN to install the module, from doing so. Thanks for the
report on that, Gerrit, and apologies for it taking months to fix this.
Cosmetic changes of small sorts have also been made for this release.
As an aside doubtless of major interest to no-one at all,
Filesys::CygwinPaths has now been put under CVS by me (its author) and
this shows beyond question (g) how serious I am about this tool becoming
majorly useful, nay, indispensible, for everyone using Perl on Cygwin
;-). This means that if a user, say, on this List finds a bug and
submits a patch, I am far more likely now to be doing something about
this week instead of next year.
To find the installation archive look somewhere around the vicinity of:
{$CPAN}/authors/id/S/SO/SOMIAN/experimental/unregistered/Filesys-CygwinPaths-0.04.tar.gz
(For those to whom this is news, unregistered in the URI above means
that the namespace for this module hasn't been submitted yet for
approval by TPTB at CPAN.).
Filesys::CygwinPaths is a collection of Perl functions (xs subroutines)
providing access to the Cygwin internal API for translating file paths
between the various modes relevant on Cygwin systems. The internal
Cygwin functions are the same as those accessed on the shell command
line by using the `cygpath(1)' command included in Cygwin (but the Perl
interface does not implement all the available internal functions,
rather just a subset). Emphasis has been placed on relative simplicity
and ease of use (and the jury remains completely out on that, since I've
received basically zero feedback on the module thus far, since its
release last year).
Please see the module POD (Perl Plain Old Documentation) which will be
installed as a manpage (or `perldoc ...') at install-time, for more
detailed information.
Soren Andersen somian -AT- pobox -DOT- com
--
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security.
-- Daisaku Ikeda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: sharing hd partition betw Linux and Cygwin
On Mon, Jun 02, 2003 at 04:04:11PM -0400, Soren Andersen (me) wrote:
{snip}
What: The entire logical partition is mounted on Linux using a mount
point /linms-common/ and the CVS area is under that
(/linms-common/SOMIANCVSROOT). A parallel arrangement (mountpoint
differing but that's all) exists under Cygwin-cvs. No problems exist (or
have manifested yet) under Cygwin, but under Linux I am having problems
with running CVS commands, and those problems are based on perms.
How (it fails): I cannot get CVS to run because it cannot write any
files to that dir.
I am trying to use the mount(1) options to the entry in my Linux
/etc/fstab uid=NNN,gid=NNN in order to correct for a potential problem
arising from differing users on the two systems. I have uid=[the numeric
UID on Win98-Cygwin] and gid=[my GID under Linux] in hopes that group
access rights are sufficient, but it turns out that they are not. By
default all files (dirs) mounted on this vfat - type filesystem under
Linux `mount' are set with perms rwxr--r-- so group members never have
'write' perms. From what I can tell from the docus for Linux 'mount',
there is no way to change this situation on a mount like
Win9x-vfat-(into)Linux.
I've fixed it myself. I set the uid= my numeric uid on Linux, not the
one on Win98-Cygwin. It probably should have been obvious to me to do so
initially, but I am pretty new to all this linux stuff.
Now sharing the drive space between the cvs tool (and cpan, too!) works,
I think (haven't actually tried cvs yet but had to work on cpan a few
minutes ago, and discovered it was suffering from the same difficulty).
Soren
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Notice of intention to release Perl module specific to Cygwin
[posted today to [EMAIL PROTECTED]; posted to [EMAIL PROTECTED] (via Gmane) in order to try to get Cygwin's worthies in the loop]. Subject: Where it runs or what it Does?? (RFC) Date: Mon, 11 Nov 2002 17:56:00 -0500 --- [[EMAIL PROTECTED] being asked:] Hi Good Folks, namespace advice requested. I have written an extension module that I need to name and get uploaded to CPAN. My Subject: line means that as I see it there are two common approaches to naming modules: where it runs (BSD::Foo), or what it does (Filesys::Bar). My inclination is to try to use 'what it does' FIRST and only resort to where it runs when I need to make it clear that there's a special purpose for the module; that it is platform-specific in some sense. I think this is (at least partially) correct Perl philosophy. The oddball module i've written is for doing some path manipulations on Cygwin. Cygwin is and yet isn't a platform; it's a posix overlayer running above Microsoft Windows. It emulates *nix to such a degree that normally we don't think about anything Cygwin-specific needing to be added; Cygwin Perl is just a very basic vanilla *nix perl with no special functionality added. Contrast with ActivePerl, which is Win32 Perl and that means special namespaces defined and all sorts of extra stuff (modules) thrown in. But there's a little fly (in my ointment). Cygwin Perl can run in all sorts of different contexts and be used for many uses. Someday somewhere somebody is going to be using Cygwinperl and want to have it tell another application FooMe.exe (thru a 'system()' call, for ex.) that it wants FooMe to do something with the file /cygdrive/r/obscure/directory/dirtypictures.jpg or ~/.initme_rc or /tmp/*.doc. And that app FooMe is a Windows app that knows nothing about posix-style paths and will upchuck on the argument. In fact, I think this HAS already happened, amazingly, to somebody, somewhere ;-) . So this module will offer the very simple service of some subroutines that will take a path as an input arg and return a path. There are four subs right now (the XSUBS are named something longer; these are perl subs): posixpath win32path fullposixpath fullwin32path And they do just about what you'd think. They access the Cygwin C API through XS glue. One trouble is that conceptually the persons involved with perl on Cygwin don't all want any sort of Cygwin:: namespace and don't really agree that there's anything unusual about Cygwinperl that differentiates it from any generic *nix perl. I know better: on Cygwin, there is always going to be more than one canonical-ly-correct way to refer to a file by path name (!!): /posixstyle/file.name--VS-- R:\something\mounted\to\posixstyle\file.name --and-- R:/something/mounted/to/posixstyle/file.name Which last, Cygwin is also perfectly happy to accept and is IMHO the ideal happy medium or lingua franca for most hybrid situations on Cygwin. People are calling this a mixed path. That's a difference. A psuedo-filesystem difference, IMO. But like it or not, find it 'easy to categorize' or not, there IS a difference (between generic *nix perl and Cygwin perl). So my present analysis is that my module belongs in a base namespace of Filesys:: and maybe could be named CygwinPaths? I think it would keep the maintainer of Cygwin Perl happy -- or should -- if named like this. What do YOU think? Best, Soren A -- conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in$CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top. -- Ziggy (via Schwern) -- http://fastmail.fm - Same, same, but different... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ANNOUNCE: mrxvt - a tabbed rxvt hack for Win32 (in development)
[posted and mailed -- sorry, no Subject: in 1st sending, this is re-sent to Rui and the Cygwin List] Re: ANNOUNCE: mrxvt - a tabbed rxvt hack for Win32 (in development) On Sat, 02 Nov 2002 22:29:36, Rui Carmo [EMAIL PROTECTED] wrote: Hello all, I've been hacking together a multiple rxvt (essentially a tabbed window holder that lets you switch between multiple rxvt windows). Sounds REAL good. The project page is at http://na-cama.com/rcarmo/index.php/Projects/mrxvt And even though it is not available (yet), I'd like to have some feedback on it (essentially food for thought). I'd also like to know if anywone is working on: - porting screen to Cygwin (it compiles great, but installation needs a lot of tweaking) - a full tabbed terminal that runs in Win32 (using W11, like rxvt). There's been discussion of that recently on the Cygwin List. See the bottom of this msg for a pasted copy of the first article i have in that thread. BTW I do not know what W11 is. Maybe most rxvt users do, I have only recently been using rxvt sometimes. Also please note this recommendation re: Please reply to me directly, since I am not subscribed to the list (my mail traffic simply cannot cope with another mailing-list...) IMHO you should be reading (subscribed to) the Cygwin List, Rui. For one thing it is of course a breach of standard List netiquette to ask for help or post a proposal for discussion and then ask for off-list replies. Netiquette aside, there's a practical reason. Suppose, as could very well happen, that in 3 weeks somebody reads this List and comes across your message, and this someone knows something that might help you or might pertain to your project. They might even know a little thing that will help you break through a deadlock you find yourself in. But this person is busy and thinks to themselves I don't know who Rui has heard from [off-List], probably he's got all the input he needs by now, I won't answer this You lose. I understand your problem with List traffic, I have long struggled with same. I have the solution for you. Go to www.gmane.org (the Gmane project) and set up Gmane server in your favorite NNTP news reader software. Subscribe to the Cygwin List as one of the Newsgroups (psuedo-newsgroups we might say, actually) once you have downloaded the long list of available ng's. Pay careful attention to Gmane FAQs and instructions. Set your newsreader if possible to use a custom header field Archive: with value encrypt particularly. (On Windows, Xnews does fine). This protects your email address from spammer harvesting; you MUST use your valid, unmunged email addy to post to Gmane ng's (contrary to popular practice on open USENET ng's). IMHO any project which brings more powerful or stable, and flexible terminal - console choices to Cygwin can add significant value to Cygwin. Your project sounds like it has good potential. I hope you get the help you need from wherever, and I hope you follow my recommendation and subscribe to the Cygwin List using Gmane so that everyone here can follow your progress and learn if they care to. Regards, Soren A --- From: Rafael Kitover caelum -AT- debian -DOT- org Newsgroups: gmane.os.cygwin Subject: Screen for cygwin Date: Thu, 24 Oct 2002 09:40:27 -0700 Message-ID: 000101c27b7c$0ebd3fc0$b900a8c0@CAELUM My version of screen for cygwin, which I actually finished putting together a month ago is here: http://www.io.com/~rkitover/screen-3.9.13.tar.gz It will configure and compile on cygwin with no tweaking. It will support detach and attach, however the terminal size issue is still there and I haven't managed to find a workaround. I tried to get these changes merged upstream but haven't received any sort of response yet. I probably need to make a cleaner patch. For now if you're interested in screen please feel free to use this! -- Rafael -- http://fastmail.fm - Accessible with your email software or over the web -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Install abnormal: latest SSH package
Hello Corinna, all, I ran setup to provide my Win98SE-Cygwin system with the SSH package last night. I let setup update several other packages as well. All went fine *except* the truly odd abnormality that SSH didn't get installed. It was downloaded (I specified install from internet) to the folder where all the packages are expected to go, but setup never tried to run an installation for that package; it was a completely silent failure too. As I wrote, everything else tagged for update or installation was installed, including OpenSSL which naturally got tagged by setup as a prereq of SSH. So I went in and manually installed the files for SSH and it's working OK, AFAICT. (Yes, I hate broadcasting the fact that I am even trying to use SSH on Win9x, but ... just have to trust that nobody reading this here would try to abuse such priviliged info). Just thought you ought to know. Best, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
CYGWIN variable: impact of options under Win9x
Hello, I am hoping that I'll get some helpful hints by posting this. I've been running Cygwin under Win98SE for months now without the CYGWIN env variable set in Windows at all. I have FAT and FAT32 partitions. My mounts are all binmode. Now I am looking at setting CYGWIN thus: SET CYGWIN=export noenvcache glob:ignorecase title nostrip_title winsymlinks tty What sort of surprises or changes in behavior (that I might not have realized were changeable behavior, i.e. things that I'd not taken heed of until now) might I experience? Since this is the Cygwin List rather than another and its character is what it is, I'll type out explicitly that: I am posting this because I have a feeling of less than perfect comprehension of the uses and ramifications of the parameters to CYGWIN, even after reading http://cygwin.com/cygwin-ug-net/using-cygwinenv.html. I am particularly keen on knowing what might not work in just the same way as before (under a default condition on Win98SE, that is in which there is no setting for CYGWIN at all) due to the last parameter tty. The document at the url given above indicates that [it is] not compatible with some Windows applications. I find that quite vague and am most unsure how concerned to be about it. I am also keen on assuring myself that not mentioning ntea or ntsec is fine; that those options would do nothing under Win98 anyway, and that Cygwin applications will run fine with them not set (i.e., *sshd*)?? My Cygwin installation at this moment: Cygwin DLL version info: DLL version: 1.3.10 DLL epoch: 19 [...] Build date: Mon Feb 25 11:14:34 EST 2002 Shared id: cygwin1S3 Thanks, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Any existing routine for CPU-id on Cygwin?
On 5 Mar 2002 at 22:34, Tim Prince wrote:
On Tuesday 05 March 2002 17:55, [EMAIL PROTECTED] wrote:
Hello,
I was just wondering if there is any existing code that's perhaps part of
the Cygwin code base or else known to some readers, that will allow
querying of the CPU type?
I'd like to have a pretty simple way to get this. One application would be
an enhanced configure for zlib-1.1.3 which would place the appropriate
assembler source for a 486, a 586 or a 686 -- for example -- into the
Makefile build formulae. I need only the generation of chip, i.e. what
Intel calls the Family.
I am thinking that maybe somebody already worked this out. I am also
thinking that instead, maybe the way this is done is in assembler and if so
maybe it hasn't been done (specific to Cygwin, that is; I have found a
couple of free utilities out there that do this from a command line). I am
just full of semi-educated guesses ;-).
It's not OS-specific. Any gcc code which does what you want should work, or
you could translate MS-style asm() syntax, as I did here:
#include windows.h
#define FAMILY_ID0x0f00 // EAX[11:8] - Bit 11 thru 8 contains family
unsigned int reg_eax = 0;
unsigned int reg_edx = 0;
unsigned int junk, junk1;
unsigned int vendor_id[3] = {0, 0, 0};
__try {// verify cpuid instruction is supported
__asm__(cpuid : =a (reg_eax), =b (*vendor_id),
=c (vendor_id[2]), =d (vendor_id[1]) : a (0));
__asm__(cpuid : =a (reg_eax), =b(junk), =c(junk1),
=d (reg_edx) : a (1));
// eax contains cpu family type info
// edx has info whether Hyper-Threading
// Technology is available
}
__except (EXCEPTION_EXECUTE_HANDLER ) {
return NO_CPUID;// CPUID is not supported and so
// it is not a recent family CPU
}
return (reg_eax FAMILY_ID);
==
That is, uhh, _WAY_COOL_ ;-). Thank you! I very much appreciate this ... and it
challenges
me (because asm makes my head hurt...).
TMTOWTDI: yours is no doubt FAR better, but just to prove that I am telling the truth
when
(in my other recent List msg) I maintain that I am not a C programmer... I cooked up
my
own solution using the ANSI library functions below. And then wrapped it in a autoconf
macro so it can be included in aclocal.m4.
Now (having exposed myself this way) maybe some people will learn to stop writing
submit a patch back at me... ;-P
watch for bad wrapping and low-flying owls --
dnl Copyright (c)2002 by Soren Andersen - written Wednesday, March 06, 2002
dnl Released under FSF GPL.
AC_DEFUN([AM_INTEL_CPU],
[AC_CACHE_CHECK(for the Intel CPU generation, am_cv_localhardware_INTELcpu,
[AC_TRY_RUN([
#include sys/utsname.h
#include unistd.h
#include stdio.h
#include string.h
int
main ()
{
struct utsname thishost;
char *intelNum;
FILE *datout;
if (uname(thishost) 0) {
exit(1);
}
intelNum = strchr(thishost.machine, 'i');
if( intelNum != NULL strspn(++intelNum,23456789) == 3 )
{
if( ( datout = fopen(conftest_cpu.data, wb) ) != NULL )
{
fprintf( datout, %3s, intelNum );
fclose( datout );
exit(0);
}
}
else { exit(1); }
}
], am_cv_localhardware_INTELcpu=`cat conftest_cpu.data`,
am_cv_localhardware_INTELcpu=no, am_cv_localhardware_INTELcpu=no)])
test $am_cv_localhardware_INTELcpu = no || CPU=$am_cv_localhardware_INTELcpu
AC_SUBST(CPU)dnl
])
--- end wrap- and owl- watch ---
The only trouble (ha-ha) with the above is that I know it *must* duplicate some
routines
found as part of the existing `autoconf' package macros. I just do not know, however,
how
to check (in a configure script) for the existence of a host_cpu autoconf value in
order to
skip my slow code and use that instead. Yes, I am fishing for autoconf pointers here.
Best,
Soren Andersen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
On 28 Feb 2002 at 11:24, Colm Aengus Murphy wrote: Hi Johan, I took a quick look at source code for make 3791-5 It looks to me like vpathc (build_vpath_lists) does conversion of Win32 paths to posix ones for the VPATH variable but not for vpath Not being a software programmer I'm not in a position to provide a patch, but maybe someone else could ? Colm A I am not a software programmer either ;-) (irregardless of the apparent assumptions made about me in the past on this List) -- at least not really a C programmer (rather, japh-er) but I will take a look at this and see if I can fix it Mind you, I wouldn't hold my breath or base my plans for a major product roll-out on my quick success; I have not yet ever tried to build `make' from source, so that's the first and possibly not trivial hurdle Maybe somebody else will therefore get there before me, but I thought I'd offer you assurance now that at least one pair of eyeballs out here will be looking into this Luck, Soren Andersen -- Unsubscribe info: http://cygwincom/ml/#unsubscribe-simple Bug reporting: http://cygwincom/bugshtml Documentation: http://cygwincom/docshtml FAQ: http://cygwincom/faq/
/dev/clipboard protection fault on Win98
Hello, I have been forgetting to write in about this. In cannot use /dev/clipboard on Win98; anything redirected to it causes a fault (Windows error box). My Cygwin is described by (`cygcheck -s', abridged): --- Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon Feb 25 02:31:34 2002 Windows 98 SE Ver 4.10 Build Path: D:\win98_Cygwin\usr\local\bin D:\win98_Cygwin\bin D:\win98_Cygwin\bin e:\SCR c:\WINDOWS\SCRIPTS d:\TOPUSR\BIN32 d:\TOPUSR\LOCAL\BIN d:\WIN98_~2 c:\WINDOWS d:\TOPUSR\BIN d:\PERL\BIN SysDir: C:\WINDOWS\SYSTEM WinDir: C:\WINDOWS HOME = `e:\home\sorenboss' MAKE_MODE = `unix' PWD = `F:/src/manualbuild/Cygbuilds/Ilib-1.1.8' Found: D:\win98_Cygwin\bin\bash.exe Found: D:\win98_Cygwin\bin\cat.exe Found: D:\win98_Cygwin\bin\cpp.exe Found: D:\win98_Cygwin\bin\find.exe Found: D:\win98_Cygwin\bin\gcc.exe Not Found: gdb Found: D:\win98_Cygwin\bin\ld.exe Found: D:\win98_Cygwin\bin\ls.exe Found: D:\win98_Cygwin\bin\make.exe Found: D:\win98_Cygwin\bin\sh.exe 601k 1999/11/08 C:\WINDOWS\SYSTEM\cygwindevo.dll 152k 2002/02/10 D:\win98_Cygwin\usr\local\bin\cygjpeg6b.dll 56k 2000/12/03 D:\win98_Cygwin\bin\cygbz21.0.dll 66k 2001/11/20 D:\win98_Cygwin\bin\cygregex.dll 41k 2002/01/20 D:\win98_Cygwin\bin\cygXpm-noX4.dll 46k 2002/01/20 D:\win98_Cygwin\bin\cygXpm-X4.dll 50k 2002/01/20 D:\win98_Cygwin\bin\cygz.dll 35k 2002/02/04 D:\win98_Cygwin\bin\cygltdl-3.dll 170k 2002/01/21 D:\win98_Cygwin\bin\cygpng2.dll 119k 2002/02/07 D:\win98_Cygwin\bin\cygjpeg6b.dll 18k 2000/10/23 D:\win98_Cygwin\bin\cyggdbm.dll 21k 2001/06/20 D:\win98_Cygwin\bin\cygintl.dll 22k 2001/12/13 D:\win98_Cygwin\bin\cygintl-1.dll 35k 2002/01/09 D:\win98_Cygwin\bin\cygform6.dll 20k 2002/01/09 D:\win98_Cygwin\bin\cygmenu6.dll 175k 2002/01/09 D:\win98_Cygwin\bin\cygncurses++6.dll 202k 2002/01/09 D:\win98_Cygwin\bin\cygncurses6.dll 12k 2002/01/09 D:\win98_Cygwin\bin\cygpanel6.dll 751k 2002/01/21 D:\win98_Cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.9 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 51 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Mon Jan 21 12:48:41 EST 2002 Shared id: cygwin1S3 Cygwin Package Information Package Version cygwin 1.3.9-1 --- Anybody else having troubles like this? Regards, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is window manipulation available in perl?
On 12 Feb 2002 at 9:04, Robert Mecklenburg wrote: First, please excuse the newbie question. I don't think this is off-topic, but my judgement isn't the one that counts. ;-) I've done a good bit of searching with google, faqs, and posting to comp.lang.perl.misc, but can't figure this out... I'm using the most recent cygwin port of perl (revision 5.0 version 6 subversion 1) on windows 2000. I want to send alt+f x to an Outlook Express window from a perl script. It seems that ActiveState Perl can do this with the Win32::Setupsup package, but that the vanilla perl (or cygwin's perl) cannot do this? I am pretty sure they cannot; why would they? Perl doesn't come from Windoze; it comes from UNI*. Anything that Perl has been taught about running on Windows and manipulating 'doze features, has happened relatively recently (relative to Perl's origin point). And a great deal of that added 'doze functionality has been added by workers for ActiveState or rolled into the ActiveState releases tho originating earlier in someone's work (G. Sarathy for ex.). Credit where credit is due. I tried to install the Win32-CtrlGUI-0.22 package from cpan.org but it requires Win32::Setupsup which is not on cpan.org. I found this package on perlring.org but it seems to require ppm. I found references to ppm at activestate.com but it appears to be a feature of ActivePerl rather than of just perl. Yes, ppm is an invention of the folks at ActiveState, specifically I think the major parts have been created by Murray Nesbitt. Look for ppm on CPAN. ppm is now distributed for everyone to use however they will (as a general- purpose utility; they envision it being used well beyond only for installation of Perl extentions). You can surely get ppm working on cygwin Perl with a bit of effort; it just isn't built-in like it is for AP. ALSO, please check the ppm file for Win32::Setupsup which might just be a gzipped-tarball inside a .zip file, with (maybe) a .ppd file and stuff? outside the tarball. Maybe not, too. But many ppm files are just an outer wrapper around a standard CPAN dist package, TTBOMK. If this is the case, you are in luck and you might just be able to build it by hand -- using the standard perl module building incantations of course. Specific instructions concerning which, BTW, would getting quite OT for this List, should they be brought up... So the question is: how to I send keystrokes to a Windows window with cygwin Perl? Absolutely likely you do not want to fruitlessly boogey with futility unless you happen to already be an accomplished Win32 programmer (and are ready to brave xs or learn 'Inline.pm'). You probably want to use the means that the existing Win32 C extentions to Perl (such as those packaged with ActivePerl) can provide. Look, cygwin Perl is not magical; it does not automatically have parallels to all the extra Win32 stuff that ActiveState has put into their product. It is what it is: an 'orthodox', useful, solid UNI*-ish *core* perl packaging. It's not a 'competitor' with AP + all the extensions that are commonly and conveniently installed with/to AP, and comparing the two is making an apples-and- oranges mistake. Generically, two of the mechanisms Windows provides for interapp communication are OLE and the ancient DDE message protocol. If you are truly feeling creative and adventurous you might start there. But I have a feeling you will probably find you need to bite the bullet in the end, install ActivePerl and port your script to ActivePerl -- if you cannot get the necessary module support installed through Cygwin Perl, which you may well not be able to. Unless you are low of disk space or something, it isn't so bad. Installing AP will only take you a few minutes and after all its a good tool to have on hand sometimes. I run both; so do many others, I think. One thing that will do for you is motivate your programmer discipline in that you'll perforce become oriented towards writing very portable scripts that don't lazily over-rely on UNI*-POSIX'isms nor on Win32-isms. Not that there aren't specific occasions when your goal is to do something very platform-specific and so non- portability cannot be avoided. HTH, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Close to libiconv now?
Hello, With the newest autotools in the official Cygwin packages, are we now close to being able to build gnu libiconv o-o-b? I am trying to build gcc-3.0.3 and it suggests that i might want to install libiconv. I understand from reading list archives that Chuck Wilson built an experimental libiconv using some hacked autotools support, last july. Any updates on that topic? Regards, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CygwinPerl Q - interact with symlinked dir?
On 20 Jan 2002 at 19:21, Gerrit P. Haase wrote: Another question: So I did this: $ ln -svdnf '/home/sorenboss/.cpan/' ~/.cpan create symbolic link `/cdv/e/home/sorenboss/.cpan' to `/home/sorenboss/.cpan/' Why didn't you mount this way: $ mount -s -b x:/cygwin/home/sorenboss/.cpan \ e:/home/sorenboss/.cpan ? I use always mount for something like this. Thanks. Well, it didn't occur to me to do that, is why. I have seldom mounted subdirs to subdirs, splicing something into the filesystem tree like that, and I think it is because I haven't understood mount very well, and therefore been nervous about what would happen. This is an area of the Cygwin documentation that could use some work, IMO. [ a little time passes..] Looking at it again, I am *seriously* confused about what you are suggesting. I thought -- and I am not claiming (and have never claimed) to thoroughly understand `mount' -- but I thought that the last arg to mount had to be a POSIX path?? You seem to be supplying two win32/DOS paths as args to `mount'. Is this good to do? Thanks Gerrit! Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RTFM'ing: readily accessible user documentation?
This is going to be my one and only engagement this week in conversing with individuals who have been trained in how they think by TV shows. On 18 Jan 2002 at 13:39, twidlar wrote: Trying to get them to reverse their decision by trying to make them feel guilty or suggesting they need therapy is pretty funny. It is little kid stuff. I am glad you were amused. Unfortunately for your no-doubt fragile sense of self-esteem, it may look to others like the object of humor is otherwise than you apparently think it is, twidlar. In one brief message, your reply has managed to mistate the facts concerning: - that there was some judgement concerning my proposal at the time I offered my replies. I read no such thing: there was no judgement, instead there was just a bit of knee-jerk reacting and rejecting out of hand (and one supportive message confirming that the issue I had was shared by others). There was no discussion of the *merits* of the suggestion (other than that setup doesn't do that -- which is a defeatist and negative non-example of genuine discussion, to which I would reply so if setup doesn't/cannot do that, then let's discuss how can it get accomplished by another means?). - that I suggested that someone needed therapy in the sense in which you apparently mean to use the phrase -- as perjorative and cynical and cliched, as a way of personally attacking people. What exactly is it that is *wrong* with therapy, anyway? - I wrote nothing that indicates I believe guilt to be a useful or valid concept. Guilt is for Judeo- Christian-Moslem believers and those unfortunates who don't think they are, but who have nevertheless not been able to disentangle their inner world processes from lifetime immersion in the ways of thinking that those cultures have become. I am not of that school of philosophy. Cygwin is an excellent product because the people developing are competent, focused, use their time well, have good technical judgement, understand their users and set their priorities well. I trust their judgement on your proposal. Good, then I wonder where the motivation for writing your message comes from? Why would you need to write it if nothing you value is threatened? Maybe you understood on a level you cannot consciously acknowledge, my words concerning pervasive personal anger and unhappiness? Well, it would just be a speculation on my part to suggest any such a thing about you. Not that the folks who have been replying negatively to my messages haven't largely been doing exactly that: with absolutely NO idea who I am they rip right ahead with abundant characterizations and critiques that base themselves on thoughtless assumptions about me. It's my intent not to follow their example, however. I have been reading this List for a long time -- along with many others. I believe that if one added up all the time I've observed some folks spend scolding others for speaking up, as you have just spent here, to me -- and instead calculated what could be accomplished if those individuals like you doing the scolding put that time to productive use (or even -- gasp -- answering the question!), we could probably have seen the completion of a `mach' kernal come out of it (for instance). It amazes me that some folks here are so addicted to reacting angrily and acting like superior, stuffy old aunts waggling their fingers at disobedient children, that they cannot see what a pointless rut they are in. Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RTFM'ing: readily accessible user documentation?
On 17 Jan 2002 at 7:54, Robert Collins wrote: I'm going to ignore your newbie-style clueslessness in the body of your email, on the assumption that you will follow this advice. I wish you wouldn't, but its up to you. You are missing the whole point. A newbie isn't going to go and subscribe to cygwin-apps: wouldn't be encouraged to (based on what she reads on the way in) and wouldn't foresee the need to. I am offering (this whole group) a (slightly synthesized) newbie viewpoint on how Cygwin (setup) looks to a newbie. I submit that it is more and more self-evident that you (and probably not you alone) *cannot* shift cognitive gears enough to imagine what the newbie experience of cygwin-setup is, and clearly don't see any need to try to do so. I believe that by composing the messages I have, I may be representing (even if in a very imperfect and partial way) what untold numbers of other readers might have *thought* of posting here, but never did. Sometimes, no matter how stubbornly one might wish that the behavior (and I mean primarily the internal intellectual behavior: how people think [ feel]) of people would fit one's preconceived grid of assumptions and preferences, it just doesn't. The overly big and vague general phrase widely used to refer to this, in our culture, is human nature. Not trying to take human nature into account at all is a pitfall for those who have desires to accomplish anything at all in the world. I myself am clumsy with words and often make mistakes that strike onlookers as lack of tact or diplomacy, but I submit that I at least know about the underlying and fundamental importance of human nature and at least struggle continuously with gaining a keener understanding of what it is. I also know that there may be a very considerable investment of a personal nature in `setup' as it has become what what it is right now. What would be unfortunate (although certainly I can live with it, personally) would be if that personal investment made by developers of Cygwin caused a general intractable deafness to user feedback which is intended constructively. Best regards, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RTFM'ing: readily accessible user documentation?
Hello,
When I try to use `info blah' on my Cygwin system I get the error
info: dir: No such file or directory
Yes, this in in the FAQ (however, alternatively, not findable by any of 5
permutations of searches I ran on the List archives, just as an aside):
--
info error dir: No such file or directory
Cygwin packages install their info documentation in the /usr/info
directory. But you need to create a dir file there before the standalone
info program (probably /usr/bin/info) can be used to read those info files.
This is how you do it:
bash$ cd /usr/info
bash$ for f in *.info ; do install-info $f dir ; done
This may generate warnings:
install-info: warning: no info dir entry in `gzip.info'
install-info: warning: no info dir entry in `time.info'
The install-info command cannot parse these files, so you will have to add
their entries to /usr/info/dir by hand.
--
It is apparently the feeling on this cygwin List that one of the first
things a new user should do is check the documentation (RTFM) that comes
with the Cygwin installation ('should do' long before they consider posting
a question to the List). Documentation that is installed on the local
machine the user is using (especially if they are a dial-up user) is
preferable to on-line documention for reasons of speed of access (or not
having to use a phone line, or not having one available). Seem reasonable?
No? Well I am sure anyone can argue about anything.
IMHO, info *should get set up automatically when Cygwin is installed.*
Placing a bunch of files into a directory then just leaving them inert and
useless seems half-assed to me, to be candid, given the recently over-
discussed noise level issue here (myself being the one who is doggedly
flogging it to death). Anyhow, that arcane invocation given in the FAQ
(arcane to someone just learning `bash' or shell scripting in general,
probably), represents setting the bar TOO HIGH on new user ease-of-access
to that important information in the preferred Gnu format (info as
opposed to man).
This is all stated *given willingness to acknowledge _human_ _nature_* of
course. Only from that perspective do I consider these my observations to
be obviously salient. From the perspective of expert users and those who
have known Gnu software for years (and probably created some of it),
looking at the matter without being able to get into the head of the
novice user impatient to begin using Cygwin, it will sound like silly
purile carping. Such a person can say so -- fine -- but will get no
sympathy from me next time they complain that the same questions keep
getting asked over and over again
The FSF info source code package for texinfo contains a README file which
contains this small notice:
* The Info tree uses a file `dir' as its root node; the `dir-example'
file in this distribution is included as a possible starting point.
Use it, modify it, or ignore it just as you like.
(ftp://tug.ctan.org/tex-archive/macros/texinfo/texinfo/README)
That source package also contains this script file (as it turns out, once
one opens it and reads it, it's a shell script -- but how would a newbie
automatically know this???):
ftp://tug.ctan.org/tex-archive/macros/texinfo/texinfo/util/gen-dir-node
Couldn't this script, or something like it, be made a part of Cygwin and
run each time a setup installation procedure is completed? Couldn't the
user AT LEAST be prompted to choose whether to run it, or advised that he
should?
That's my suggested addition (for today) to whatever it is that `setup'
does. I am not currently involved in hacking on `setup' so I won't be
contributing any patches on this issue; it will have to fall to someone
else to (maybe) implement this, for the time being (other priorities are
just unrefusable for me at present). Thanks for your attention.
Soren Andersen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Proposed Mailing List Page Reorg
On 14 Jan 2002 at 21:32, Robert Collins wrote: contribute patches. Contribute the links *you know* (come on' after more than a years use you must have collected a few useful links). Don't worry about whether they are the best links, that's what open source doco is for! Well, yes, exactly! Collectively this List's readers must possess in one form or another a prodigious pile of reference knowledge about where to look for answers. If we pool our knowledge we will achieve the several benefits of both lowering the noise level on the List (perhaps) and making it more interesting, and also of helping others (and probably ourselves) to more quickly target rich sources for areas where enriched knowledge is required. If *you* don't, and noone else *does*, then nothing will happen, and in 6 months Chris will say I've been cogitating... Sounds pretty frightening! ;-) I am picturing Spike on Buffy the Vampire Slayer (American TV show, sorry for the non-global reference) emerging from the shadows with that malevolent smirk on his face, saying I've been cogitating.. ;-[ Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Proposed Mailing List Page Reorg
On 15 Jan 2002 at 10:41, Robert Collins wrote: Soren, this is *discussing* it, if you wish to address it, then contribute a patch - to the web site, the FAQ - wherever you think it should go. I'll get to work on it, for sure. I don't say this to cut short the discussion, but because no-one has disagreed in any substantial way with what you are saying, and no-one has steppted forth to do it Oops! I must be slipping ... if I'm not getting somebody to strongly disagree with me ...heh heh Best regards, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Proposed Mailing List Page Reorg (was: RE: No stderr output)
On 10 Jan 2002 at 20:55, Gary R. Van Sickle wrote:
[cgf wrote:]
If this doesn't do it, then I think the best plan is to find help from
another mailing list. Basic shell questions are not really appropriate
here -- especially given the recent volume we've been experiencing.
I've been cogitating for a while that it could be mutually beneficial to
inexperienced users and regulars' blood pressures alike if the Cygwin
mailing list page listed a few concrete URLs to such newbie
lists/newsgroups/FAQs etc, and at the same time reworked the wording on the
description of this particular list.
Oh yes. I can tell you from a semi-novice POV that this is a correct
insight. The wording (on that page at the RedHat Cygwin WWW site) that
describes and therefore implicitly invites and directs towards the Cygwin
mailing list could be re-written to important benefit for all, including
both the tired veterans and the clooless noobies who think they are reading
ask us anything at all here about using Cygwin, we'll get you fixed up:
Currently it says, If you have questions about how to use Cygwin, or
any of its tools (bash, gcc, make, etc.), this is the list for you.
That means: If you have any question whatsoever regarding anything you
can associate somehow with Cygwin, post it here.
can associate being the most significant phrase in this point. The
trouble is that experts' notions of *where* the boundary between OT for
Cygwin lies and the noobie notions of where it lies (or that such a thing
might exist, more to the point), is potentially extremely different, and
whole sets (myriads, hecatomes) of assumptions need to be examined for
correctness, which apparently aren't:
- can one safely assume that a noobie who finds Cygwin grasps that the
tools that are packed with cygwin (bash, login, man, for example) aren't
specific to Cygwin at all but long predate it, and
- can one safely assume that noobies will think these tools that i am
given with Cygwin run the same 'on cygwin' as they do on any Uni* -like
platform (and therefore general documentation 'out there' will apply too),
and
- can one safely assume that noobies who might even guess at the first two
points might not think anyway that maybe I'll find friendlier, more
sympathetic folks to hold my trembling timorous hand here, than I would if
I ventured onto onto the Wierd Wild Web in search of generalized help on
these tools? (Point of this last is not to characterize the cygwin list as
nasty or to propose that it self-characterize this way, but to suggest
that a LITTLE warning of a slightly stern-sounding nature at the front
door might be expeditious and appropriate given that folks on this list
BAL [By And Large] clearly DON'T want anymore to answer questions like
what does man do or how do I login to bash).
It may be that In The Ancient Past most people who installed Cygwin were
experienced Uni* users who longed for familiar tools in some kind of
circumstantial Windoze exile they were enduring, but this also may not be a
safe assumption anymore, if it ever was (IMO is not, since I knew little
about Uni* when I began using Cygwin several years ago). So this means an
entire philosophical framework (i.e., the Uni* Way -- small user-
configurable tools chained together in innumerable combinations to
accomplish novel tasks, rather than Monolithic User Interfaces from one
company where all the parts are considered more-or-less to be the Operating
System itself... and only conventional tasks are allowed to 'exist') may
be lacking for noobies of this description.
Yep, assumptions lie near the root of cygwin List unhappiness.
That's simply not the intention of the list (at least since I've been
around), nor should it be, but the description simply gives no
indication of the true intent, i.e. Cygwin-specific questions only
need apply.
Now as for where best to send people, I have no idea (maybe some can just
point into the appropriate section of the FAQ). But here's a rough outline
of what I'm thinking:
{snip}
Unless there is one single extremely knowledgeable and encyclopedically-
oriented person who knows where to send people (and such people do exist I
think, but whether one will care to undertake this is another question)
then I think that a little project (or a little coordinated multi-person
collaboration, for lovers of ornate terminology!) needs to be created to
develop and verify a list of
resources to send such visitors to.
The task (of writing up re-directions for some of these categories or
inquiries) can be done once, -- to set up more precise explanations and
info at the site; or it can be done as its been done, repeated over and
over again as similar questions appear on the list and are answered one at
a time.
Best,
Soren Andersen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http
Re: Updated Gnu tools manpages, maybe you'd like to know? ('gnumaniak')
On 7 Jan 2002 at 13:11, Gerrit P. Haase wrote: Soren Andersen [EMAIL PROTECTED] wrote: creating more updated man pages for (many of the core) Gnu apps we use ... http://www.userfriendly.net/linux/RPM/contrib/noarch/noarch/gnumaniak-1. 4-1.noarch.html ftp://ftp-linux.cc.gatech.edu/pub/linux/docs/man-pages/ ftp://ftp-linux.cc.gatech.edu/pub/linux/docs/man-pages/gnumaniak-1.5.tar.gz But this file is about two years old...probably are the most manpages at your current Cygwin installation more up to date;) I wonder about how we would know that. Oh, I suppose someone could get very serious and look at each page for a revision date (I don't know `man' well enough to be 100% sure, but I think I recall that a revision date is part of the formatting...). My point is however, if GNU say they are no longer trying to keep man pages current, then how can we know how out-of-date any arbitrary one might be? maybe you have inside information (by inside I mean access to facts about GNU which are not first-glance general knowledge or something like that). If you do have a specific reason to believe you know (i don't mean to sound combative, you just didn't support your contention with anything, leaving -- imho -- a question in the reader's mind) that the Cygwin- installed apps' man-pages are going to be more current than something dated in 1999 or 2000, pls tell me. Thanks --for the urls, great! , Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
IMAP c-client under Cygwin
I want to develop a Perl solution for accessing an IMAP server and doing things like querying messages in a folder named blahfoo, telling the server to move messages from blahfoo to cowpuddle, etc. I have researched and there is a Perl module collection for doing IMAP client stuff, but it requires UW c-client library support files to be linked in during the module build. My question concerns info on whether anyone reading has worked with IMAP and the c-client distro on Cygwin (I guess that I mean worked with more than by merely installing PINE, which i think some users might have done, but I don't know how much knowledge of building c-client that would give one if its a pre-built Cygwin binary you've installed...)? Can anyone offer pointers on building, or refinements to the source package documentation? I tried once to build it last month and it did not go well (sorry, this message cannot attempt to explain the errors, that was done last month on another system 400 miles away from where I am right now...). In this communication I am just soliciting advice and also inviting those interested to speak up and share knowledge about how to get a clean build of this lib so that we can do neat things... BTW, there is a great e-mail service provider at `fastmail.fm', that has POP3 and IMAP access as well as an intelligently designed Web interface to email (and is currently in beta, so they are not charging for use of their service -- once they start charging they promise no ads! -- ever). Check their site for details. This is the server I wish to access with the software I am aiming to develop. My GUI email client, Pegasus v4, has unfinished and problematical IMAP support. Thanks, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
IMAP c-client under Cygwin
[I tried to send this message once but it apparently did not go through from that address. Sorry if it duplicates] I want to develop a Perl solution for accessing an IMAP server and doing things like querying messages in a folder named blahfoo, telling the server to move messages from blahfoo to cowpuddle, etc. I have researched and there is a Perl module collection for doing IMAP client stuff, but it requires UW c-client library support files to be linked in during the module build. My question concerns info on whether anyone reading has worked with IMAP and the c-client distro on Cygwin (I guess that I mean worked with more than by merely installing PINE, which i think some users might have done, but I don't know how much knowledge of building c-client that would give one if its a pre-built Cygwin binary you've installed...)? Can anyone offer pointers on building, or refinements to the source package documentation? I tried once to build it last month and it did not go well (sorry, this message cannot attempt to explain the errors in great detail, that was done last month on another system 400 miles away from where I am right now... but briefly, the source for c-client is written to expect an MSVC++ compilation environment on Win32; there is no built-in support for any alternative Win32 platform...) In this communication I am just soliciting advice and also inviting those interested to speak up and share knowledge about how to get a clean build of this lib so that we can do neat things... BTW, there is a great e-mail service provider at `fastmail.fm', that has POP3 and IMAP access as well as an intelligently designed Web interface to email (and is currently in beta, so they are not charging for use of their service -- once they start charging they promise no ads! -- ever). Check their site for details. This is the server I wish to access with the software I am aiming to develop. My GUI email client, Pegasus v4, has unfinished and problematical IMAP support. Thanks, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
as parameters. Only a Cygwin binary can interpret these
symbolic links. If a symbolic link were specified as a parameter to a MinGW
compiler tool, it would fail. Thus, I fail to see how MinGW GCC over Cygwin
is a better solution than MinGW support provided by Cygwin GCC.
That makes sense to me.
While I do think Cygwin GCC currently does a great job of supporting MinGW,
I do have a few issues with it:
{snip details}
Hopefully this can all get resolved peacefully and harmoniously. The one
thing I hope is that the
collective attitudes at minGW never get to the point where people over
there (some of whom are also people over here) have forgotten the debt
of appreciation they owe to cygwin, for being the historical predecessor
and host that allowed them to come into existence, if for nothing else.
Opinionatedly Yours,
Soren Andersen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: IMAP c-client under Cygwin
On 8 Jan 2002 at 22:56, Gerrit P. Haase wrote: Am 2002-01-08 um 21:16 schriebst du: I want to develop a Perl solution for accessing an IMAP server and doing things like querying messages in a folder named blahfoo, telling the server to move messages from blahfoo to cowpuddle, etc. I have researched and there is a Perl module collection for doing IMAP client stuff, but it requires UW c-client library support files to be linked in during the module build. There is already a module for that and it builds without errors if you build the c-client of the cygwin imap package, see here what I needed to change: http://testers.cpan.org/search?request=distdist=Mail-Cclientmacid=130 Gerrit keeps coming to my aid ;-). Thank you! I will study your work, how fortunate I feel that you've been the one to do this. I asked in the right place, for once, it appears! My question concerns info on whether anyone reading has worked with IMAP and the c-client distro on Cygwin (I guess that I mean worked with more than by merely installing PINE, which i think some users might have done, but I don't know how much knowledge of building c-client that would give one if its a pre-built Cygwin binary you've installed...)? Can anyone offer pointers on building, or refinements to the source package documentation? You need to build the c-clientlib from source, the library isn't included in the package, but the source - http://sourceforge.net/projects/uw-imap-cygwin/ I understand you to mean that these files: imap-2000a-cygwin-bin.tar.gz 4454129 1,571 i386 .gz imap-2000a-cygwin-src.tar.gz 1363877 793 i386 Source .gz neither do contain a c-client.a lib? I cannot get a connection to the server to download right now; maybe in a few minutes. Until I can download I cannot look inside the archives to see what's there. Assuming I understood you correctly, what is in the binary package, is only the compiled imap library archive (and headers, naturally), is this probably correct? That would be a shortcut? Will this allow my build of the client to be more simple? The exact relationship of c-client to the imap library isn't clear to me, even after reading the maintainer's documentation over two occasions (today and last month). Maybe now it will all be simple and i won't need any more help with the UW IMAP C library part of the Perl work i want to do. I will holler if that isn't the case, tho :-). Hmm, Google didn't find this sourceforge project for me. Surprising! Thank You, Soren -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with cygwin GCC and -mno-cygwin switch
On 8 Jan 2002 at 19:14, Christopher Faylor wrote:
On Tue, Jan 08, 2002 at 05:29:14PM -0500, Soren Andersen wrote:
This lack of sponsorship maybe is also part of the noted tendency for
minGW priciple persons to manifest some, uhh, let's say testiness.
I've been reading the mingw mailing lists for a while and I really don't see
anything like this. Most of the replies are very courteous.
Of course they are. I never meant to suggest otherwise. But sometimes...
They don't seem to have anyone like me, for instance. :-)
I don't know what to make of that, precisely. It doesn't seem to me that
you manifest particularly obnoxious behavior.
I've seen all this from certain people involved in minGW. Overall,
though, its an amazing thing that minGW even exists, and has
accomplished as much as it as.
I really don't see very much of this at all. I'm surprised to see this
observation.
Well, everyone experiences different things. That is a large general truth
about life in all sorts of realms, far beyond just online or just among
hackers on mailing lists.
But specifically in reply, Chris, since I was, I thought, VERY careful to
preface and intersperse all my comments with things like I don't mean to
dis anyone at minGW, I hope that somehow an overly broad and vague and
erronious impression isn't created by this, your response, which seems much
more concerned [as in worried] than I feel would be warranted by a
reading of my message that accurately grasped my intent (which was first of
all to praise cygwin).
One thing that is pretty clear to me is that there is no one person,
aside maybe from Mumit Khan, who can legitimately present him/herself
as speaking for minGW. I think that needs to be acknowledged if
there's been some impression that minGW is criticizing cygwin. minGW is
first and foremost a free-for-all, a collaborative exercize that moves
forward by fits and starts. In any such assemblage of personalities there
are bound to be some outspoken individuals (no sh__:-) who express
frustrations they are having in a way that isn't echoed by more silent
participants.
There is a group of core MingGW maintainers, or at least that's what I
understand.
A couple of the MinGW maintainers have actually indicated
that they still use cygwin for building their compiler tools.
Yes, AFAIK that is true, and is another discussion I'd like to have
sometime.
And, as may have been noted, the mingw web page is really not wrong.
MinGW support in cygwin *is* flaky and we *have* talked about
deprecating it.
I don't know much about that, relative to others here and over there.
Since your involvement in cygwin (and this List) is continuous and daily
and mine is perforce sporadic, I can never authoritatively contest anything
you state regarding past statements and discussions. Nor do I see any need
to.
[note: OP wrote]
From what I've seen, it looks like MinGW support in Cygwin GCC is
up-to-date and better than ever before. So, I have no idea what the
MinGW web site is referring to. Does anyone from Cygwin agree that
MinGW support will be deprecated?
{snip}
[I wrote]
Hopefully this can all get resolved peacefully and harmoniously. The
one thing I hope is that the collective attitudes at minGW never get to the
point where people over there (some of whom are also people over here)
have forgotten the debt of appreciation they owe to cygwin, for being the
historical predecessor and host that allowed them to come into existence,
if for nothing else.
[cgf:]
There is no over there.
Of course there is. If one refrains from placing inferred nuances into my
words, all that my words meant (like the words of the OP) is that there is
a minGW community, vaguely -- as you indicated, a core group of
maintainers, whom I have much respect for -- and that community has its own
Lists and sites (as cited by the OP). And maybe or maybe not (debatably)
its own collective prevailing attitudes.
The MinGW maintainers are a friendly bunch. I scan the MinGW lists for
cygwin issues and a number of them read the cygwin list as well.
As I believe I said?!?
So, please don't invent any antipathy between our two groups.
Perhaps *you* individually saw my words as an attempt to do so, hopefully
that wasn't a widespread impression. I think going back and looking at the
msg of the OP is warrented if one is going to debate my intention any
further after I have made this reply. There is IMO a clear probability that
the OP's msg may be read by some people as evoking the sense that there's
controversy or disharmony between cygwin and minGW.
My message was addressed to that possibility, not to fan any flames but to
provide historical perspective to those who might be catching up -- as
there are always many newcomers to any special-interest discussion in this
large realm, be it GNU or Apache or Mozilla or whatever -- people who
weren't involved from the early inception stages and may
Re: Potential problems with cygwin GCC and -mno-cygwin switch
cgf wrote: Hmm. Have you been reading the mingw mailing lists? That wasn't clear. I don't see any messages from you but I've only been archiving them since August or so. And ... does that (august of 2001) seem like a long time ago, to you? So that you can feel pretty confident about being aware of what things have been like since that community began to nucleate? Hmm. No, Chris, you'd definitely have to access archives back WAY further to find messages posted by me. Years further. I can see you love to scrap. You are pretty good, although I've met better Ur-nitpickers in my time. But pretty darn good! ;-) Best Regards, Soren Andersen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
