ProFTPd usable on WinXP-HE, questionable to me
cygcheck.2003.Jun.22 Description: Binary data -- 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: win32 dia and HOME=/usr/bin/%USERPROFILE% fix
Brian Koehmstedt <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>
> I had the problem of bash starting up with the home directory being
> /usr/bin/%USERPROFILE%.
>
> I searched the mailing list and came up with a January thread on the
> issue, which informed me that the problem was due to the win32 dia
> installer creating a Windows environment HOME variable that superceded
> bash's normal HOME.
OK, glad you found a solution. I have no idea what "dia" is (sometimes I
wonder a bit if people posting to Cygwin have any idea how much software is
available for _any_ OS (e.g., GNU/Linux), let alone MS Windos, and how
unlikely it is that their interests and pursuits coincide with those of
other regular readers...), but if it sets a HOME variable in the Windows
environment, then that would indeed be where Cygwin starts the user,
instead of under Cygwin's (POSIX-style hierarchy) "/home{USER}" dir.
Come to think of it, I do know what dia is, it is an Open Source drawing
and diagramming tool.
But I have to point out for posteriors ... oops, I mean for *posterity*,
that this isn't a BUG in Cygwin, this is a FEATURE. I personally *want*
Cygwin to honor my setting of $HOME (%HOME%) because I keep my user dir
files outside the Cygwin fs hierarchy (makes my life easier if I decide a
total wipe-and-reinstall of my Cygwin installation is necessary). Also, I
may want some other, non-Cygwin software to be able to use a HOME dir that
Cygwin knows about too.
> Edit the cygwin.bat file and put "set HOME=" somewhere in it. This
> unsets the Windows HOME environment variable and Cygwin/bash starts up
> with the correct HOME environment variable.
To wrap up, I have to challenge this erronious understanding. Bash's
"correct" HOME directory is what you TELL it is HOME unless you don't
really mean it. Unlike some software systems,
Cygwin's BASH (or any BASH) doesn't assume it knows better than the user.
Soren A.
--
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
"Gary R. Van Sickle" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> Subject: ProFTPd usable on WinXP-HE, questionable to me > > Windows XP - High Explosive edition? ;-) > Heehee. I didn't choose it (to install). "HE" = "Home Edition". -- 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
"Soren A." <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > > Attachment decoded: cygcheck.2003.Jun.22 > --==_=_37794.70672821764D1BD3B9== Sheesh. Did Gmane trip me up? There WAS all this text before the attached `cygcheck` output: - Hello! I've been trying to set up ProFTP on a WinXP Home Edition system with Cygwin and it isn't working. My efforts include reading "README.cygwin" under /usr/doc/proftpd/ and making the suggested changes (insofar as I could understand the meanings in the document) to /etc/proftpd.conf. I understand that the ftpd has to have privs like "SYSTEM" and that looking at past List messages, Jason Tischler says "run it as 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). So in the /etc/proftpd.conf file I have lines like: User SYSTEM Group Administrators 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. 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). 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"? The user management interface on WinXP that is where I'd look for changes like those available under NT4, for changes various user rights, just isn't there, AFAICT. Alternatively, is there anything that can be done to convince ProFTPd to run as another user? I've tried (since the original broken posting) to start ProFTPd as another user via "runas", but it won't start the service that way (I ran the config script and then runas "net start proftpd"). The service appears in the Admin tool under "services" but trying to restart it always fails (i.e. it is always in a "stopped" state). Also I cannot get a commandline to "runas" that will work from bash, my only success has been from a CMD.exe prompt. How are people doing this? Sorry to be bitchy about it and thanks to all those who have contributed to this port. Soren A. PS. I am posting from Gmane. -- 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
Vince Hoffman <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Is this any help ? > http://archives.postgresql.org/pgsql-cygwin/2003-03/msg00047.php Huhh. I guess I am screwed, because NTRights.exe looks like it is what I need, but it's only made available as a file in the NT/Win2K Resource Kit, and I am 6 months into moving lock, stock and barrel into basing nearly everything I do on GNU/Linux. At this late hour I am not about to pay M$ for the ResKit, when I have declined to do so for all these years. Especially since I only wanted to FTP a few files from a crippled SSHd machine (that's only able to run one logon client ssh session at a time, so cannot "scp" out a file back to the "client" machine, which is my typical strategy for finding a file on Linux and copying it to a Cygwin box). So I can run a lesser ftpd I guess, or find another way to do this. Thanks anyway, although it is frustrating, it is a tiny bit gratifying to know that I was right about sensing that there was a "hole" in M$ tools provided for this task and that something exists to fill that hole. Soren A. -- 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
"Soren A." <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Huhh. I guess I am screwed, because NTRights.exe looks like it is what > I need, but it's only made available as a file in the NT/Win2K > Resource Kit, Hehe. Altavista to the rescue, when Google fails. Thx agin. S. A. -- 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/
example needed pls: `cygpath -c '
[posted and mailed]
Hi! The ever-fascinating "cygpath" tool once again beckons to me to plumb
its depths ...
I am trying to finish a test script that uses ActivePerl to call `cygpath`
from itself (a system call, by open()-ing a pipe to capture the output of
the tool ...
{... stuff ...}
open(CTH, '-|', "C:/cygwin/bin/cygpath $MS_path_filename")
or die "Could not open() call to 'cygpath', what is up?";
$cygstyle_path = ;
chomp $cygstyle_path;
{... stuff ...}
(troubled?: `perldoc open' or read the Camel 3rd Ed.;
this is the new {$] >= 5.6.1} 3-argument form of open().)
I tried simple backticks too ;-). The point is that I get every indication
by rigorously checking the return values of the calls to open(), close()
and checking Perl built-in vars $! and $?, that the call to cygpath
*worked*, but when I try to examine the string returned ($cygstyle_path),
it is always empty!
So anyway, I am chasing all geese of any degree of domestication at this
point. I've tried searching in the several ways and cannot believe
no-one has asked before, but: please someone, provide an example of the
use of the "-c" flag to "cygpath", e.g.
cygpath -c -u 'C:\\foo\\bar\fump.rey'
What values should "" have? I do not really understand the
manual explanation of what this flag is for. Could it help me here?
Any other insights also appreciated.
A couple of answers to anticipated questions from the idle
onlookers ;-) ... :
* yeah, am using AS Perl, that's because this is a piece of
a WSH script.
* what I'd like to end up with is a way to context|alternate-click
on any filename in MSWindows Explorer and place the filename as
*cygwin*, not the OS, will see it, on the clipboard. Anyone
already had a pass at this wheel?
Soren A.
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
--
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/
example needed pls: `cygpath -c '
[posted and mailed]
Hi! The ever-fascinating "cygpath" tool once again beckons to me to plumb
its depths ...
I am trying to finish a test script that uses ActivePerl to call `cygpath`
from itself (a system call, by open()-ing a pipe to capture the output of
the tool ...
{... stuff ...}
open(CTH, '-|', "C:/cygwin/bin/cygpath $MS_path_filename")
or die "Could not open() call to 'cygpath', what is up?";
$cygstyle_path = ;
chomp $cygstyle_path;
{... stuff ...}
(troubled?: `perldoc open' or read the Camel 3rd Ed.;
this is the new {$] >= 5.6.1} 3-argument form of open().)
I tried simple backticks too ;-). The point is that I get every indication
by rigorously checking the return values of the calls to open(), close()
and checking Perl built-in vars $! and $?, that the call to cygpath
*worked*, but when I try to examine the string returned ($cygstyle_path),
it is always empty!
So anyway, I am chasing all geese of any degree of domestication at this
point. I've tried searching in the several ways and cannot believe
no-one has asked before, but: please someone, provide an example of the
use of the "-c" flag to "cygpath", e.g.
cygpath -c -u 'C:\\foo\\bar\fump.rey'
What values should "" have? I do not really understand the
manual explanation of what this flag is for. Could it help me here?
Any other insights also appreciated.
A couple of answers to anticipated questions from the idle
onlookers ;-) ... :
* yeah, am using AS Perl, that's because this is a piece of
a WSH script.
* what I'd like to end up with is a way to context|alternate-click
on any filename in MSWindows Explorer and place the filename as
*cygwin*, not the OS, will see it, on the clipboard. Anyone
already had a pass at this wheel?
Soren A.
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
--
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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 28 Jun 2003
news:[EMAIL PROTECTED]:
[Soren A.:]
>> I am trying to finish a test script that uses ActivePerl to call
>> `cygpath` from itself (a system call, by open()-ing a pipe to capture
>> the output of the tool ...
>>
>> {... stuff ...}
>> open(CTH, '-|', "C:/cygwin/bin/cygpath $MS_path_filename")
>> or die "Could not open() call to 'cygpath', what is up?";
>> $cygstyle_path = ;
>> chomp $cygstyle_path;
>> {... stuff ...}
>
> If $MS_path_filename is indeed a regular Windows filename (with
> backslashes) you will need to either use quotemeta() or s!\\!/!g
> because singular backslashes will be removed during interpolation.
I know this. Already checked that what's being fed into `cygpath' is
kosher.
I've spent 4+ hours debugging this script.
> 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;
>
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.
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
--
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 '
Soren A <[EMAIL PROTECTED]> wrote around 28 Jun 2003 news:[EMAIL PROTECTED]: > [posted and mailed] > > Hi! The ever-fascinating "cygpath" tool once again beckons to me to > plumb its depths ... Sorry for the dup posting. Please follow-up to the other twin if possible. Explanation: well, I seem to have more troubles posting to the List than normal people. I frequently work at several different machines setup in different ways at different places, and do my Cygwin conversations as I can (carpe diem). I recently had to subscribe via a new email account and my newsreader had to have settings changed to reflect that. I posted two or more articles yesterday that never showed up on the List, via Gmane, so for this message I decided to buy insurance in the form of posting-and-mailing. Again, apologies. I have no explanation for why it didn't work yesterday, I haven't changed anything between then and now (but maybe closed and then re-started Xnews, that could account for it). Soren A. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 01 Jul 2003 news:[EMAIL PROTECTED]: > Soren Andersen wrote: > >> 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. > > Yes, it's quite dumb code. It doesn't even work correctly if one of the > files doesn't exist. However it works perfectly for what I originally > devised it for, which is using Windows editors from cygwin, as in I have > the line > > alias ue="dodos /path/to/uedit32.exe $@" > > in .profile, and so I can issue commands like "ue /etc/hosts*" or "ue > ~/project/foo*.c" to edit files with UltraEdit as if it was a > cygwin-aware application. Yes, I get it. That's a valid use for this simple thing. Thanks. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 01 Jul 2003 news:[EMAIL PROTECTED]: > Brian Dessent wrote: > >> Save this as a text file ending in .txt and then open it: > > I meant .REG not .TXT.. silly. > > Brian That's OK: you are reaching an initiated person here (although goog to correct the erratum for archival reasons). I do have a puzzlement, sorry if it seems like I am not sufficiently trustful (but anything having to do with making changes to my Windows Registry sets off "max caution" alarms, as it of course should). (Previously you wrote:) > Replace your cygwin path as appropriate. Use "%1" instead of "%l" to > get the short-filename version. As written above, you'll get values > such as "/cygdrive/c/Program Files/Microsoft Visual Studio" copied to > the clipboard, the space might be problematic. With "%1" you get > something like "/cygdrive/c/PROGRA~1/MIAF9D~1". Where does this distinction between the letter "%l" (that's percent-symbol followed by alphabetic letter "L" in lowercase) and the string of tokens "%1" (that's percent-1, numeral "one" symbol), come from? Is this some in(f|t)ernal MS Windows Registry thing? ;-) >> - >> REGEDIT4 >> >> [HKEY_CLASSES_ROOT\Directory\shell\CygPath] >> @="&Copy Cygwin Path" >> >> [HKEY_CLASSES_ROOT\Directory\shell\CygPath\Command] >> @="c:\\cygwin\\bin\\bash -c \"echo -n `/bin/cygpath -u >> '%l'`>/dev/clipboard\"" >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPath] >> @="&Copy Cygwin path" >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPath\command] >> @="c:\\cygwin\\bin\\bash -c \"echo -n `/bin/cygpath -u >> '%l'`>/dev/clipboard\"" - Much appreciated. Soren A. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Doug VanLeuven <[EMAIL PROTECTED]> wrote around 01 Jul 2003
news:[EMAIL PROTECTED]:
> Just goes to show.
> I didn't want to get into asp but I created this wsh file
> checkpath.wsf
> ---
>
>
> $MS_path_filename="c:\\bin\\gzip.exe";
>
> $WScript->Echo("$MS_path_filename");
> open(CTH, '-|', "D:/cygwin/bin/cygpath $MS_path_filename")
> or die $WScript->Echo("Could not open() call to 'cygpath', what
> is up?");
> $cygstyle_path = ;
> chomp $cygstyle_path;
> $WScript->Echo("A" . "$cygstyle_path" . "B");
>
>
> --
> pretty much your original post.
> I'm finding it only works with AS perl 5.8.0.805.
That's the version I have been trying this on. Confusing.
> In 5.6.1.633 the return value is empty but 5.8 works as expected.
Hmmm.
> I tried this first with cygwin 1.3.21 & 1.3.22 and
> before & after upgrading to 5.6 windows script host.
> Can't blame cygwin
So! Oooo-Kay! Wow, that's an amazing result. It seems there's a major
wonkiness afoot, but AFAICT I must agree, it seems that "cygpath" is
blameless here.
Now we know (and have a major headache-generator available for future use
should such a mystery demand further investigation).
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
--
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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 01 Jul 2003 news:[EMAIL PROTECTED]: > It took a bit of work, but the perl5-porters mailing list had enough > nuggets to get it going. I wrote up the steps here: > > http://www.dessent.net/patk/archives/35.shtml That's a fsck-ing holy grail I sank double-digit hours into some time ago (and never succeeded). Outstanding. I commend you and shout "major kudos" for getting this to work and documenting it for others. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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/
phantom non-existent command "manpath"?
Hello, I've a question on the cygwin port of `man' and it may turn out that it is pertaining to `man' in general everywhere. I have come across a shell script that is part of a software package, that uses the command output of `manpath' to fill the variable MANPATH: export MANPATH=`manpath` When I `man man' I see that the top of man's own manpage references manpath in a line right below the heading for `man' itself. But after that I could find no clear explanation further down for how `manpath' (LOWERCASE) works or why it wouldn't be available on all systems where `man' itself is installed. Nonetheless on my Cygwin installation `manpath' is absent. Is this right? Upstream maintainers bogus documentation warts aren't Cygwin's responsibility (just in case anyone mistakenly infers that I am implying such) but since cygwin is where I am using `man' in this context (and where I am testing the aforementioned software package that is going to break because `manpath' isn't available), I am hoping a knowledgeable reader will come up with some insights to help me understand what's up. Is there a technique for replacing that one-line (above) i.e. an obvious kludge I could employ? Until I really understand what `manpath' does I can't come up with one myself. TIA. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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: phantom non-existent command "manpath"?
Soren A <[EMAIL PROTECTED]> wrote around 01
Jul 2003 news:[EMAIL PROTECTED]:
> I've a question on the cygwin port of `man' and it may turn out that
> it is pertaining to `man' in general everywhere.
I'm sorry, my bad.
I read more carefully after finding a reference explaining `manpath's
intended functionality elsewhere, and realized that `man' itself DOES have
flags to execute the functionality simulated by `manpath':
-w or --path
Don't actually display the man pages, but do print the loca-
tion(s) of the files that would be formatted or displayed. If no
argument is given: display (on stdout) the list of directories
that is searched by man for man pages. If manpath is a link to
man, then "manpath" is equivalent to "man --path".
-W
Like -w, but print file names one per line, without additional
information. This is useful in shell commands like
man -aW man | xargs ls -l
Answered my own question.
Bye!
Soren A.
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050
--
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 '
CygPathExpandSZ.reg Description: Binary data REGexpandSZgen.p Description: Binary data -- 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 '
Soren A <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > Attachment: CygPathExpandSZ.reg > Attachment: REGexpandSZgen.p My newsreader is buggy, if I attach it makes the body text just vanish. Here's what accompanied those attached files when I hit "send" 10 minutes ago: --- Brian Dessent <[EMAIL PROTECTED]> wrote around 01 Jul 2003 news:[EMAIL PROTECTED]: > I think by default it tries to use short-filenames in some cases, and > so %L means the same as %1 except it uses long file names. Well you are so right. And your knowledge about this stuff inspired me to forge onward in pursuit of inspiration. I have dressed up your .reg file a bit (heheh) and now give it back to you ... mutated beyond recognition ... (also attached to [previous] posting, so don't sweat) - 8< - snip and de-indent and de-wrap - 8< - REGEDIT4 [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN] @="&Copy LFN Cygwin Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN\Command] @=hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,5c,62,69,6e,5c,5c,62,61,73,68,20 ,2d,63,20,5c,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74 ,68,20,2d,75,20,27,25,6c,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72,64 ,5c,22,22,d,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN] @="&Copy LFN Cygwin path" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN\command] @=hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,5c,62,69,6e,5c,5c,62,61,73,68,20 ,2d,63,20,5c,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74 ,68,20,2d,75,20,27,25,6c,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72,64 ,5c,22,22,d,00 [HKEY_CLASSES_ROOT\Directory\shell\CygPathSFN] @="&Copy SFN Cygwin Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathSFN\Command] @=hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,5c,62,69,6e,5c,5c,62,61,73,68,20 ,2d,63,20,5c,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74 ,68,20,2d,75,20,27,25,31,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72,64 ,5c,22,22,d,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathSFN] @="&Copy SFN Cygwin path" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathSFN\command] @=hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,5c,62,69,6e,5c,5c,62,61,73,68,20 ,2d,63,20,5c,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74 ,68,20,2d,75,20,27,25,31,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72,64 ,5c,22,22,d,00 - 8< - snip and de-indent and de-wrap - 8< - OK, "what's UP with this bizarre thing?" It is a REG_EXPAND_SZ -type REGEDIT .reg file instead of using easy REG_SZ -type entries. The expansion encoded is of a variable %CYGROOT% which must be present in the Windows "master" environment, so that the Registry _always_ has access to it. I set it in my Windows9x autoexec.bat file of course, and under NT/2K/XP you can use the ControlPanel|System. I really feel that %CYGROOT% is a broadly useful thing to do. Point it at the top (mounted as /) of your Cygwin installation and you'll always have programmatic access to the Cygwin location from outside in the 'doze wilderness. It's always nice to know where your safe haven is located, no? This is a typical Cygwin installation example of %CYGROOT%: SET CYGROOT=C:\cygwin (in autoexec.bat). So when I run the file above (I named it "CygPathExpandSZ.reg"), the Registry entries thus created are expanded with the result that whatever is in %CYGROOT% gets prepended to locate bash in cygwin's /bin. This makes your .reg concept portable without manual editing, to any system that has the %CYGROOT% variable defined in the env (obviously that's not very many since this isn't any part of Official Cygwin). Since you cannot (easily) read it you'll have to trust me that what I've described is what it does ;-). But here's the file _before_ creating the right kind of entries (this *will not work* as a .REG file, it could be termed "Registry psuedo-code"): - 8< - snip - 8< - !nope!REGEDIT4 messed up by my news client! [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN] @="&Copy LFN Cygwin Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN\Command] @="%CYGROOT%\\bin\\bash -c \"echo -n `/bin/cygpath -u '%l'`>/dev/clipboard\" " [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN] @="&Copy LFN Cygwin pa th" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN\command] @="%CYGROOT%\\bin\\bash -c \"echo -n `/bin/cygpath -u '%l'`>/dev/clipboa rd\"" [HKEY_CLASSES_ROOT\Directory\shell\CygPa thSFN] @="&Copy SFN Cygwi n Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathSFN\Command] @=&
Re: example needed pls: `cygpath -c '
Brian Dessent <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > "%CYGROOT%\\bin\\bash -c \"echo -n `/bin/cygpath -u > '%l'`>/dev/clipboard\"" + NewLine > > When I run the command I get an error. The proper quoting is > > "%CYGROOT%\bin\bash" -c "echo -n `/bin/cygpath -u '%l'`>/dev/clipboard" > > You don't want to escape the double-quotes because they are there to > tell the windows shell to make all that stuff a single arg, after -c. > You need double quotes around the exe image in the off chance there's > a space in $CYGROOT. This is fun and bizarre because on win98SE this seems to work for me; the whole thing "just works". Windows is SO inconsistent. One thing that complicates comparison of my setup with others is that my Windows "shell" (the kind shipped by M$) is set to "CMD.exe" from a Win2K SDK that "mostly" runs on Win9x, instead of the "normal" COMMAND.COM. It is entirely possible I think that the first pass at processing the command is being done by whatever %COMSPEC% points to and that the two would have (do have) different quoting rules should come as a surprise to no-one. > And there's the issue of the raw binary newline at the end. That was a goof, I was too close to bedtime to try to send in a fix for that before turning in. > The hexified version of that is > hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,62,69,6e,5c,62,61,73,68,22,20,2 > d,63,20,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74, > 68,20,2d,75,20,27,25,6c,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72 > ,64,22,00 > > > > > Anyway, the Right Way (IMHO) to do this would be something like the > following Escalated to C! Yeah! OK, NOW we're rockin'. ;-) More later. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > I agree that REG_EXPAND_SZ is "nicer" in terms of not hard-coding > paths, but since $CYGROOT is non-standard I don't see that it matters > too much. Yes . (Finding this so much fun, there's nothing like throwing megatons of programming technique at a tiny little problem that several readers are no doubt snickering at ...). So, next escalation is to either write a dialogue (either in the C version or sticking to scripting, maybe cook up a .WSH script). If doing the scripting version, we'll have Perl do some heuristics, first checking for %CYGROOT% and accepting whatever that is, IF it is defined, and next, looking in the "standard" (M$-speak: "well known") place (C:\Cygwin), and if that fails write code to find a Cygwin key in the Registry and pull the install location out of that. OR we could just tell users that they must execute it in the CYGROOT (top of Cygwin location), and find a way to put the cwd into the .REG entries before executing. Now that I think of it, the latter is the most sensible notion, if we were sticking to scripting. But I like the C version which is far superior. Anybody know how to put a little Cygwin icon next to the context-menu entries where "SFN CygPath" and "LFN CygPath" appear? ;-) (this is most likely an OLE / COM thing and far more work than it's worth... ?) More later... -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Brian Dessent <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > Oops, I left off a call to GlobalFree(hglbBuffer); before exiting. Or > maybe not, I'm not sure with this global heap business that you have to > use when working with the clipboard... Anybody know if the system frees > that clipboard data the next time the clipboard is emptied, or do you > have to do it before your program exits? You did it right. A book I have [Windows 98 Developers Handbook, Ezzell & Blaney, Sybex, 1998] says Do not under any circumstances free memory after transferring a data object to the clipboard. [...] The result of calling GlobalFree would delete the item from the clipboard. Instead, once a data item has been transferred, ownership of the item has also been transferred, and the local handle should not be used or tampered with further. You are correct in guessing that the next time an application calls EmptyClipboard the global memory is freed by the Clipboard itself. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Soren A <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > So, next escalation is to either write a dialogue (either in the C > version or sticking to scripting, maybe cook up a .WSH script). If > doing the scripting version, we'll have Perl do some heuristics, first > checking for %CYGROOT% and accepting whatever that is, Oops, sorry, I hadn't really read the C yet when I wrote that. It doesn't need what I am talking about, so ... nevermind. ;-) -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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/
CygPath to Clipboard (was: example needed pls ...)
Hey, 'bout time to change the Subject: and start a new thread, eh?
---Reference to Previous thread---
Subject: Re: example needed pls: `cygpath -c '
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]
Xref: main.gmane.org gmane.os.cygwin:32852
---end references---
> Soren A wrote:
>
>> The expansion encoded is of a variable %CYGROOT% which must be present
>> in the Windows "master" environment, so that the Registry
>> _always_ has access to it. I set it in my Windows9x autoexec.bat
>> file of course, and under NT/2K/XP you can use the ControlPanel|System.
> I was wondering why I didn't have any CYGROOT set. I agree that
> REG_EXPAND_SZ is "nicer" in terms of not hard-coding paths, but since
> $CYGROOT is non-standard I don't see that it matters too much.
>
> There's a couple of problems with it still, in the backspaces/quotes
> department. Your .reg file installs the command:
> "%CYGROOT%\\bin\\bash -c \"echo -n `/bin/cygpath -u '%l'`>/dev/clipboard\"" + NewLine
> When I run the command I get an error. The proper quoting is
>
> "%CYGROOT%\bin\bash" -c "echo -n `/bin/cygpath -u '%l'`>/dev/clipboard"
>
> You don't want to escape the double-quotes because they are there to
> tell the windows shell to make all that stuff a single arg, after -c.
> You need double quotes around the exe image in the off chance there's a
> space in $CYGROOT. And there's the issue of the raw binary newline at
> the end. The hexified version of that is
> hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,62,69,6e,5c,62,61,73,68,22,20,2d,63,20,22,65,63,68,6f,20,2d,6e,20,60,2f,62,69,6e,2f,63,79,67,70,61,74,68,20,2d,75,20,27,25,6c,27,60,3e,2f,64,65,76,2f,63,6c,69,70,62,6f,61,72,64,22,00
>
>
>
>
> Anyway, the Right Way (IMHO) to do this would be something like the
> following:
>
> - copy_cygpath.c -
> #include
> #include
>
> int main(int argc, char **argv)
> {
> HGLOBAL hglbBuffer;
> LPTSTR lptstrBuffer;
>
>
> if(argc != 2) {
>
> // usage: copy_cygpath [win32 path]
> return 1;
> }
>
> hglbBuffer = GlobalAlloc(GMEM_MOVEABLE, (MAX_PATH +
> 1)*sizeof(TCHAR));
> if (hglbBuffer == NULL) {
> return 1;
> }
>
> lptstrBuffer = GlobalLock(hglbBuffer);
> cygwin_conv_to_full_posix_path(argv[1], lptstrBuffer);
> GlobalUnlock(hglbBuffer);
>
> if(OpenClipboard(NULL) == 0) {
> // failure!
>
> GlobalFree(hglbBuffer);
> return 1;
> }
>
> EmptyClipboard();
> SetClipboardData(CF_TEXT, hglbBuffer);
> CloseClipboard();
>
> return 0;
> }
> --
>
> $ gcc copy_cygpath.c -o copy_cygpath.exe -mwindows -luser32
> $ mv copy_cygpath.exe /bin
OK, Brian, your copy_cygpath tool works just fine (sans the issues
of providing fancy escaping a' la' `ls'). But I cannot get the
Registry to accept the entries now! Each time I try I get the keys
created OK, but the "command" is undefined (I am writing of how we
see the Registry in "regedit"). Somehow, my guess is that REGEDIT
is not liking the way the data entries look and is blanking them
out when adding the values to the keys.
> Now your registry entry is just:
>
> "%CYGROOT%\bin\copy_cygpath.exe" "%1"
That's a numeral "one" (1), not an "l" (letter L) -- that gives us
a SFN, not a LFN, no?
> or
>
> --
> REGEDIT4
>
> [HKEY_CLASSES_ROOT\Directory\shell\CygPath]
> @="&Copy LFN Cygwin Path"
>
> [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN\Command]
> @=hex(2):22,25,43,59,47,52,4f,4f,54,25,5c,62,69,6e,5c,63,6f,70,79,5f,63,79,67,70,61,74,68,2e,65,78,65,22,20,22,25,31,22,00
> --
I have been using double backslashes! It worked fine in the previous,
bash-based script version. Let me try with single backslashes in the
path to copy_cygpath and see if THAT works. Growl. I had it working
beautifully the previous way, now all this fussing... ;-)
(More previous message reference:)
> This has the advantage of loading a single process, rather than bash,
> echo, and cygpath. You also eliminate the silly console window that
> flashes open and then closes.
>
> One might also want to change the C code to backslash escape spaces and
> other non-[\w\d] characters. That way you could still work with the
> long filenames at the command prompt
Re: CygPath to Clipboard (was: example needed pls ...)
Soren A <[EMAIL PROTECTED]> wrote around 02 Jul 2003 news:[EMAIL PROTECTED]: > I have been using double backslashes! Does not seem to matter, still cannot get it working. But I discovered a significant bug in the Perl tool (REGexpandSZgen). Please throw out the one attached earlier and go to the url below to get the latest debugged version. http://perlmonks.org/index.pl?node_id=270750 The bug: wasn't null-padding to two chars, the hex representation of each byte, for certain small numbers (ordinals). Now it does. It of course also properly chomps() off the newline as Brian pointed out. Best, Soren -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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 '
Brian Dessent <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I was wondering why I didn't have any CYGROOT set. [...] since > $CYGROOT is non-standard [...] A little more about $CYGROOT. It also makes the cygwin.bat file used by default to start bash more flexible. We can do something like this (works under NT/2K/XP TTBOMK): snip! 8< - Cut Here - @echo off :: My part -- customizations SET CYGWIN=noenvcache check_case:adjust title ntsec export SET PATH=%SystemRoot%\System32;%SystemRoot% CALL :FindMe %CYGROOT% GOTO :EOF :FindMe SET CYGHOMEDIR=%~d1 %CYGHOMEDIR% chdir %CYGROOT%\bin SET CYGHOMEDIR= IF EXIST rxvt.exe GOTO :rxvtterm GOTO :EOF :rxvtterm rxvt -display ':0' +vb -cr '20,252,123' -ls -C -sk -sr -sl 3600 -geometry '122x48+0+0' -fg '#94C9E0' -bg '#061212' -fn 'Andale Mono-15' -e bash --login -i GOTO :EOF :bashconsole :: Default -- standard part bash --login -i snip! 8< - Cut Here - So, %CYGROOT% isn't standard, but I find it's highly useful ;-). -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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: CygPath to Clipboard (was: example needed pls ...)
Yes, a bit OT, but could be useful to understand more about it... Soren A <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I cannot get the Registry to accept the entries now! Each time I try I > get the keys created OK, but the "command" is undefined (I am writing > of how we see the Registry in "regedit"). Still no joy. On a WinXP system (the other I refer to is Win98) I used the regedit tool to look at some REG_EXPAND_SZ entries already in the Registry, and exported a key for examination. What I discover if I do this seems *BIZARRE* (but we are talking about Microsoft here so nothing ought to surprise us). I see the string of hex bytes exported as we have been discussing, but each one _is followed by a null byte_. Thus one entry I examined looks like this: "TEMP"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\ 00,25,00,5c,00,54,00,45,00,4d,00,50,00,00,00 Do you see what I mean? "25,00,53,00,79,00: ... . If *that's* the format RegEdit expects (and it could have changed between 98 and XP, anyone know?) then it would certainly explain why I haven't been able to get any subsequent tries to work. Even the terminating null is followed by a null. Now I am scratching my head so hard my hairline is imperiled... Soren A. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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: CygPath to Clipboard (was: example needed pls ...)
"Stephan Mueller" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Looks like it's the hex-encoded representation of some Unicode text > (each character is a 16-bit entity). For plain ASCII values (e.g. > English text), yes, you'll see every other byte as a zero. Gratitude! Thanks Stephan. Yes, you must be right, and it's what we'd expect WinXP to do, what with the overall move to Unicode uniformity. Still putting all the clues together ... -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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: CygPath to Clipboard (was: example needed pls ...) - Copy_Cygpaths.reg.gz (0/1)
Soren A <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > But I cannot get the Registry to accept the entries now! Each time I > try I get the keys created OK, but the "command" is undefined (I am > writing of how we see the Registry in "regedit"). Somehow, my guess is > that REGEDIT is not liking the way the data entries look and is > blanking them out when adding the values to the keys. OK. I have "reverse engineered" from a dumped key using the superior WinXP regedit tool. I now have, attached to this file, a successful .REG file (gzipped) that does what we want & expect with Brian's little copy_cygpath.exe tool placed in Cygwin's /bin/. Incomplete results still for Win9x. I am either at one machine or the other at a time, not both. So this attached file *WILL NOT WORK* for versions of REGEDIT prior to 5.00 (which IIANM debuted with Win2K). Note that the leader line is different than that familiar from the REGEDIT4 .REG files: - snip! - 8< - Cut Here - Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN] @="Copy &LFN Cygwin Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathLFN\command] @=hex(2):22,00,25,00,43,00,59,00,47,00,52,00,4f,00,4f,00,54,00,25,00,\ 5c,00,62,00,69,00,6e,00,5c,00,63,00,6f,00,70,00,79,00,5f,00,63,00,79,00,67,\ 00,70,00,61,00,74,00,68,00,22,00,20,00,22,00,25,00,4c,00,22,00,00,00 [HKEY_CLASSES_ROOT\Directory\shell\CygPathSFN] @="Copy &SFN Cygwin Path" [HKEY_CLASSES_ROOT\Directory\shell\CygPathSFN\command] @=hex(2):22,00,25,00,43,00,59,00,47,00,52,00,4f,00,4f,00,54,00,25,00,\ 5c,00,62,00,69,00,6e,00,5c,00,63,00,6f,00,70,00,79,00,5f,00,63,00,79,00,67,\ 00,70,00,61,00,74,00,68,00,22,00,20,00,22,00,25,00,31,00,22,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN] @="Copy &LFN Cygwin Path" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathLFN\command] @=hex(2):22,00,25,00,43,00,59,00,47,00,52,00,4f,00,4f,00,54,00,25,00,\ 5c,00,62,00,69,00,6e,00,5c,00,63,00,6f,00,70,00,79,00,5f,00,63,00,79,00,67,\ 00,70,00,61,00,74,00,68,00,22,00,20,00,22,00,25,00,4c,00,22,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathSFN] @="Copy &SFN Cygwin Path" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\CygPathSFN\command] @=hex(2):22,00,25,00,43,00,59,00,47,00,52,00,4f,00,4f,00,54,00,25,00,\ 5c,00,62,00,69,00,6e,00,5c,00,63,00,6f,00,70,00,79,00,5f,00,63,00,79,00,67,\ 00,70,00,61,00,74,00,68,00,22,00,20,00,22,00,25,00,31,00,22,00,00,00 - snip! - 8< - Cut Here - Soren A. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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: CygPath to Clipboard (was: example needed pls ...) - Copy_Cygpaths.reg.gz (1/1)
Copy_Cygpaths.reg.gz Description: Binary data
RE: CygPath to Clipboard (was: example needed pls ...)
I had written: > Thus one > entry I examined looks like this: > > "TEMP"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,0 > 0,74,\ > 00,25,00,5c,00,54,00,45,00,4d,00,50,00,00,00 Mystery is done. There are two kinds of .REG file: ANSI and Unicode. The Regedit tool on WinXP exports keys to .REG files as Unicode, naturally. Furthermore it is a known thing that the REGEDIT tool included in Win95/98 is *not capable* of *importing* a key that contains a REG_EXPAND_SZ datum. It is either a bug or a missing feature, depending on who you read. I downloaded a trial version of Resplendent Registrar (http://www.resplendence.com) which seems like a kick-a** tool, and made the needed additions to the Registry using that tool instead of via a .REG file. For the purposes of Win9x, all that Perl hacking was for nought. Microsoft strikes again. -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" OpenPGP Key at http://savannah.gnu.org/people/viewgpg.php?user_id=6050 -- 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/
So now you're a BigShot now? (clarification re. "MinGW Glib")
o feel that what amounts to a defeat
and a betrayal of the principles of interdependence (and that which
ought to accompany it: openness and basic showing basic respect for
others) is "OK" behavior. Whatever it is that people think they see
elswhere in the World -- from CEOs and politicians and the like -- the
fundamental truth is that this decision to pay one's self off with
indulgence of one's arrogant nature is a deal with the devil.
Again, I wrote:
>This is unbelievably unfriendly to novice users of Autoconf-based
>'configure'. Somewhere there is this incredible disconnect in which
>people like yourself say "users of XXX don't know about lib/ or DLLs"
>but then expect someone who would be willing to try running a
>'configure' script to be an all-out Guru with nearly supernatural
>powers of diagnostic insight.
The point of all this verbiage is *not* that I cannot accept criticism
of a patch I show or submit. I am only a fallible human and so my
suggestions aren't 100% perfect. But it is the _basis_ on which I have
been seeing objections raised that motivates me to compose this article.
More and more I have been seeing people respond in a dramatically
close-minded way, saying what amounts to "that's a stupid waste, it
isn't necessary." This kind of reaction is indicative of the kind of
creeping rot in people's brain cells that I have been describing above.
Because that IS what Arrogance does: it rots your brain (mind).
Criticizing someone for *working too hard* or making extra effort to
make things easier for users is backwards, wrong, foolish,
narrow-minded. And it has impacts that subtract from the vibrancy and
betterment of our whole F/O software movement.
I am not suggesting that being a package maintainer means you ought to
be a doormat for abusive people to wipe their feet on, and I am far from
ignorant of the massive quantities of painfully ignorant ("clueless")
pleas for help you'll get from users who never learned to help
themselves by RTFM'ing before bugging the author. Or from the people who
just write "it doesn't work!" without giving the slightest effort to
providing descriptive detail so you can find an answer for them. I've
spent my time in the old USENET (and yes, even CompuServe before it
ended); many 1000's of hours trying to help newbie users out. I've paid
those dues and I know what I am talking about.
What I am seeing is that some maintainers seem to have no sense
whatsoever of there being a possible middle ground between being a
passive doormat and adopting a posture of passive-aggressive, full-blown
unresponsive arrogance.
Somebody wrote to me:
> > -dnl Initialize maintainer mode
> > +dnl Turn on maintainer mode to save users from Automake Hell.
>
> I don't think GLib's configure.in is the right place for statements
> like this. Personaly, I don't think Automake is that bad. It's libtool
> which is the worst (most complex, hard to read, slow) of the auto*
> tools.
My response was:
> I do not give a damn whether anyone thinks it is appropriate. The
> brief phrase "Automake Hell" does not even begin to convey how much
> trouble, how many umpteen gazillion wasted man-hours has been
> caused by the fundamental design decisions / policies of the
> 'automake' authors. Placing it in a 'configure.ac' script that
> users might read is my expression of my right to Free Speech (which
> somewhere along the line WAS connected to what Free Software was
> supposed to be about) and what's more, is done with the intention
> of emphasizing to anyone who is or might become the author of a
> 'configure.ac' file or become a package maintainer, just how
> crucial this belated Automake band-aide is (absent any better cure
> for the badness that Automake inflicts on users).
I'd like to make the following request. If you, the reader, is a package
maintainer or will become one, and particularly if you decide to base
your package build configuration of full-blown Autotools treatment with
Automake as well as Autoconf and GNU libtool, then please consider this
well.
If you are going to adopt the attitude that simply hacking out a basic,
standard Autotool'd build-config is all that's required by the standard
of Software professionalism / quality that you choose to adhere to, then
please put a BIG logo or something on your site so that I can avoid you
and your software like the Blue Plague. Something like
*** *** *** *** *** ***
* *
* M A D E W I T H A U T O M A K E *
* *
*** *** *** *** *** ***
ought to do the trick. That way I won't have to go to the trouble and
waste the time downloading your tarball, unrolling it and getting set to
build only to discover that it is Yet Another Half-Assed Autotool'd
Package (YAHAAP). And I won't have to pull out my Virtual VooDoo Doll and
sticky-note your name to it.
Your Cassandra,
Soren A
--
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: So now you're a BigShot now? (clarification re. "MinGW Glib")
Corinna Vinschen <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > On Sat, Sep 28, 2002 at 11:23:21PM +, Soren A wrote: >> [Boringly long mail] > > *Yawn*, hmm? Oh, I'm sorry. I didn't listen. Did you say something? Well, it got you to yawn, signalling that you are still alive (for which I am glad) and therefore I can ask you: are you still maintaining Autotools for Cygwin (the package)? Soren A -- 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: So now you're a BigShot now? (clarification re. "MinGW Glib")
"Francois de Campagnolle" <[EMAIL PROTECTED]> wrote in 001801c267eb$ffb7b440$58c00d50@exostation:">news:001801c267eb$ffb7b440$58c00d50@exostation: > Don't be so lengthy if you want to make your point, especially on > mailing lists where we have tons of mails to deal with every day. It's > not a style contest (hopefully). I didn't really ask for feedback on the length of the post, or its style. FYI, the post is going to be made semi-permanent on Kuro5hin (www.kuro4hin.org), maybe. But just in answer to your unsolicited critique about the posting length: the "point" I am making requires not much less than the number of words I used. It is interesting to note that both complaints about the length (not the substance or meaning, but simply the length) came from non-native English participants in this List. As a matter of fact, I find Corinna's parts of the Cygwin FAQ (that she's authored) generally incomprehensible and incomplete -- confusing and misleading (to the point that it once a while back caused an off-list tussle between myself and one very good fellow here because I was laboring under a miscomprehension caused by misleading words in the FAQ). Basically the problem is that the parts of the FAQ she's authored are too *un*verbose. There is a profound connection between your sniping about the length of the article and my article itself. As somebody noted to me in a private reply to my post, people at his project started using Autotools in their build configuration some time back, and *really* hate them. But he thinks what they hate isn't just the Autotools themselves but the _size of the problem domain_ and how transparent that size is when using the Autotools (IOW the Autotools exist to address a "problem domain" that is large, and are rather transparent in their functioning so that the extent of the problem [cross-platform portability issues] isn't well-hidden from the user). The point is that yours and Corinna's complaint about the length of my article is an example of ignoring the true magnitude of the "problem domain". The problem's true nature really is that (fortunately, and I wouldn't want it any other way) contributors to Cygwin here are from diverse international backgrounds and yet we all have to use a common human language to express more difficult, non-code ideas -- English -- that is a big struggle to those not raised with it as their native language. Neither you nor Corinna "owned up" (were fully honest about or demonstrated awareness of) the true nature of the "problem domain" -- what you found objectionable, unwelcome or difficult about my article. Until we have truly accurate and powerful machine translation from one human language to others, this is going to go on being a problem. One doesn't make a problem go away by ignoring it feigning ignorance of its true nature. I submit that the immediate solution is *not*, however, that I, as a native English speaker, should dumb-down my posting (an extraordinary one, unusually broad and abstract in its topic) because some readers here have a handicap with reading written English. Is it? Should Francophone peoples be forced to abandon traditional French idioms and phrasings and substitute them with imported (borrowed) English ones? The French seem to feel emphatically "no" as they have written a law onto their books concerning this. I claim it is my right to use my native language to the full power of my expressive ability *when the topic demands it* and not to be required by List coercion (rules, peer pressure) to hold back or use only short words and phrases in short articles. I claim that if a French person implies I should do otherwise, there's a double standard being applied there at the very least. Food for thought. Soren A -- 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: So now you're a BigShot now? (clarification re. "MinGW Glib")
"Conrad Scott" <[EMAIL PROTECTED]> wrote in 01d601c267f8$92661870$6132bc3e@BABEL:">news:01d601c267f8$92661870$6132bc3e@BABEL: > Cheers, Please refrain from signing a flame with a benevolent parting like "cheers". It merely demonstrates a complete lack of sincerity and as such detracts from the overall climate of a List. Soren A -- 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: So now you're a BigShot now? (clarification re. "MinGW Glib")
"Chris January" <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > > Chris Thanks for not ending your flame with a phony gesture of comraderie. THAT's how to do a flame right. :-) ;-) Soren A -- 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: Cygwin port of the Unix 'script' utility.
Alan Evans <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > To compile the code I used: gcc -o script script.c -lutil > Hope this helps someone > > cheers > AlanE > > Here is the code if anyone is interested: Yes, Thank You, I am interested. Soren A -- 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: Moving cygwin discussions to Usenet? (e.g., alt.os.cygwin)
Eduardo Chappa <[EMAIL PROTECTED]> wrote around 30 Sep 2002 news:[EMAIL PROTECTED]. edu: I have finally decided that it would seem a little _strange_ if i _didn't_ get my 2c in here since some (with overall historical memory of past posts) will recall some rather strident messages authored by me. But I have, I should note, already written privately to Eduardo (in support of his proposal, btw). > *** Philippe Bastiani ([EMAIL PROTECTED]) wrote today: > >:) > Either actually read the mailing list via email as intended or >:read ) > it via news. >:) >:) We can read/write messages via news.gmane.org server... >:) >:) But, IMHO, a group of discussion would be very useful: for the >:) beginners, for 'repeat' questions and problems, ..., for any debat >:) concerning Cygwin! > > I agree with a proposal of this type, which should be completely > separate from this list, and where people can discuss anything related > to cygwin (even ask stupid questions, in whatever sense a question may > be stupid). I agree conditionally, that is, I *do not* agree with the wording "any debat[sic] concerning Cygwin. Not that I foresee that there is much anyone could do to direct an unmoderated USENET newsgroup in any direction or another; but to the extent that there will be a notion of a CHARTER (I hope???) for this not-yet-existant ng, and to the extent that that there will be (maybe) a core of relative "experts" with some base of familiarity with Cygwin, I would hope it will *not* include the idea that future development directions, in-depth re-engineering of the internals, etc [of Cygwin] would be discussed. IMHO the existing Cygwin Lists are the right place for that, if any place is. > I see why someone would like to keep all the mail related to cygwin in > one list, but I also see why some people would like to reduce the > number of messages getting to them (yes I know about gmane.org, but > gmane.org is not USENET, just one server, which has been slow for me > sometimes) There are several separate issues being discussed here. The question of reader (participant) convenience is separate from topicality. I use Gmane to read Cygwin now and it is the best thing to happen to me since I left AOL/CompuServe years ago ;-). Gmane does not do anything to *change* how the Cygwin List *works*, however. Except that the user now has a news interface (NNTP) onto a Mailing List (instead of having to cope with receipt of overly numerous individual email messages), and there's a great feature that email addresses are munged (encrypted) by the system to reduce spammer harvesting. That isn't going to happen with an open USENET newsgroup, btw, and all participants who might post there are going to have to deal with the full force of the predatory mutant beast that is today's Internet Spammer. So, the existence or non-existence of Gmane doesn't have much to do with whether or not a USENET newsgroup is to be created. But Chris had in this thread repeatedly written "Mailing List" where what was being discussed is a newsgroup, and I guess that he just 'miswrote' himself. If it works, the USENET cygwin ng could support the further growth of Cygwin, where "growth" is being defined as something like "numbers of individuals in a satisfied user base." Judging from his words, Chris is primarily interested in a definition of "support" or "growth" that is *not* what I just defined but is instead something more like "promoting the technical improvement and extension of Cygwin as a software system". The two notions, which on the surface are very distinct from each other, have a potential interrelatedness: when a "user base" grows, new individuals with new ideas and at least slightly) differing skillsets, will be supported to maintain involvement in using Cygwin. Involvement in using Cygwin can potentially lead to questions about how Cygwin works (or doesn't in some particular context) in detail, internally. Asking questions (of one's self) about that could lead to people deciding to put effort into coming up with solutions. THAT promotes Chris' definition of "growth of Cygwin". Please note the careful use all through the above para of "potentially" and "could" (as opposed to the alternative explicit or implicit "will," "should," or "certainly"). One further note concerns use of specific terminology (as mentioned above). I do not know of such a thing as a normal mechanism for "crossposting" between a USENET ng and a Mailing List. With extra effort it is of course theoretically possible but it isn't "normal" since most mass users employ a different client app (or at least a different mode in an application suite) to do the two different pr
Re: Moving cygwin discussions to Usenet? (e.g., alt.os.cygwin)
Christopher Faylor <[EMAIL PROTECTED]> wrote around 01 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > [I don't seem to I've replied to Chris off-list. Please, don't anyone follow-up to this message. Please. There's no need for it and nothing of value would be accomplished. Thanks, Soren A -- 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: Moving cygwin discussions to Usenet? (e.g., alt.os.cygwin)
raphael <[EMAIL PROTECTED]> wrote around 01 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Is just arogance nothing more. At least it shows a complete > unawareness of reality. You will never ever change a MS-Word user into > a VIM or EMAC user. And why would you? I have to say that I really disagree with this. The specific example given especially. I was once an "MS Word user" and now I use (G)VIM (even to compose email). There is simply no comparison (on any level) between the two. GVIM is the motherload of programmer-friendliness and insanely clever extentions and capabilities and user comfort; MS Word is designed for something completely different and does that in a way that many people feel embodies haphazard development, obscene program bloat and gross security openings. Discussing the merits of either program here is probably OT, of course. My point is that my *own personal experience* since starting to use Cygwin years ago (in the days of b20) is that I have been converted, step by step, from a Windows orientation to a *nix orientation. I do not agree that Cygwin is a blend of the two or should be seen as such (if anything is close to a blend it would be MinGW, a topic that is ALSO _OT_ for this List). Cygwin is an _overlay_, not a blend. So when I read somebody saying "such and such is arrogance" but I know that my own actual experience confirms the plausibility and insight of the thing which is being called arrogant and erronious, I feel I should speak up. Experience (actual proof, empirical results) beats theory any day of the week. IMHO. Soren A -- 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: Successful Build of rpm-4.0.3
"Max Bowsher" <[EMAIL PROTECTED]> wrote around 21 May 2002
001a01c200e4$fde5e240$[EMAIL PROTECTED]:">news:001a01c200e4$fde5e240$[EMAIL PROTECTED]:
> --=_NextPart_001_0016_01C200ED.5F024A70
> The attached shell script contains the steps I used to build rpm-4.0.3
> (with its included db) on an up-to-date cygwin. It is heavily based on
> the instructions by Mario Schmidt at
> http://rtfm.shagged.org/~mario/cygwin
Max, Hey, thanks for posting this. I am wondering if you could provide
more information re. porting 'rpm' to Cygwin. Even tho this posting is
months old.
The url above (~mario ...) is bad now. And I went to the official rpm
site and then burrowed into ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.0.3/,
installed the source tree.
I ran the script and it didn't quite finish installing stuff (LOTS of
stuff) before it ('make') died with some hard to understand error but it
did get far enough that I have a working rpm setup, good enough at least
to run 'rpm2cpio FOO.rmp | cpio -i...'.
Do you have any plans to propose rpm as an official Cygwin package? And
are you interested in making the build more simple? Now that db3 is
available for Cygwin, most of the dependencies that are shipped as
bundled sources with rpm-4.0.3 can be satisfied by already-installed
cygwin packages, if one can figure out the linking details and so forth.
Last observation: providing a build script like that is really a nice
contribution, probably beats heck out of merely providing a verbal
description of "how you did it".
Best,
Soren A
--
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: Tk?
"Tiller, Jason" <[EMAIL PROTECTED]> wrote around 04 Oct 2002 ADBFFED9CB40D5118C5A0008C7864BA10185AE2C@USSVML03:">news:ADBFFED9CB40D5118C5A0008C7864BA10185AE2C@USSVML03: > Enjoy, and thanks to everyone who made this possible! You're welcome ;-) And yes, just to clarify, to the O.P.; this Perl Tk is using native Windows GUI interfaces, *not* any X server interface. That's feasible and dictated by the way the Tk-Perl extension is set up: at build time, one gets to make a choice of which configuration to create. So just because it is built to and extends cygwin perl, doesn't dictate that it must use a cygwin port of X (XFree86). Soren A -- 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: Patch to get bc 1.06 to compile under Cygwin with readline library.
Francis Litterio <[EMAIL PROTECTED]> wrote around 03 Oct 2002
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> I downloaded and installed the Cygwin source code to bc 1.06, but it
> would not build under Cygwin 1.3.12-2 when {...}
Thanks for your posting. 'bc' is a useful tool and sometimes shell
scripts just don't come together at all easily without it.
I cannot verify the need for or methodology of your patch, yet, but
thanks for posting.
Best,
Soren A
--
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: Tk?
"Gerrit P. Haase" <[EMAIL PROTECTED]> wrote around 05 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > This version is linked against perl-5.6.1, Soren Anderson has managed > to build later versions of TK and has also logs at his site, > unfortunately I couldn't reproduce it for perl-5.8 :-( Hmm! I wonder what was the obstacle. Anyway, you mentioned my site but a reader might wonder 'where?' (although really should be able to find the past List messages by searching the archive, granted). So here's a url: http://home.att.net/~perlspinr/perlproj/pTk/index.html Regards, Soren A -- 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: pasting clipboard always adds carriage return
f m <[EMAIL PROTECTED]> wrote around 14 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > I'm using cygwin-1.3.12-4 on WinME. I find that when I cut something > from the cygwin window, it always has a carriage return at the end > regardless of what application I paste it into. This only happens for > text copied to the clipboard from a cygwin window. I have checked > "Quick Edit" and unchecked "Fast Pasting". I can't find anything > about this in the FAQ, cygwin mailing list archive, or google. Is > there a way to prevent this? I always see this also, on Win9x. WinME is descended from Win9x. That is, IMHO, the nature of the problem: it is an artifact relating to the Windows console in these M$ OSs. It isn't a "Cygwin problem" I think. I've just learned to live with it. It isn't fixable by anything you can check or uncheck in Windoze. HTH, Soren A -- Just say NO to YAHAAPs! (http://groups.google.com/groups?&selm= Xns92991EB1F396ngrATT586ID%40204.127.36.1) -- 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: New cygwin & .dir_colors
"Jelks Cabaniss" <[EMAIL PROTECTED]> wrote around 14 Oct 2002 001c01c273af$bee42910$6601a8c0@blackie:">news:001c01c273af$bee42910$6601a8c0@blackie: > Just installed the new cygwin and the old directory listing colors are > no longer recognized. Now it only distinguishes between normal files > (red), directories (dark blue), and links (cyan). It used to > distinguish between the file types too, i.e., .zip, .c, .txt, .jpg were > all in different colors. Why does the new cygwin not allow this, or > better, how do I enable it with the new cygwin? I do not know for a fact anything about "old vs. new". In what I am going to suggest, I am making no claims whatsoever about something changing or not changing or being broken or fixed. Step 0: what does `echo $TERM' show on your system? AFAIK it should be "cygwin". Step 1: generate another colors file: dircolors -p >~/default_dircolors Step 2: open in a text editor (`vim ~/default_dircolors') Step 3: look near the top of the file for the TERM listings. You'll know what i mean when you see it. many, many lines each beginning with "TERM" and followed by a unique name. *** IS "cygwin" one of those entries ??? *** If NOT, Step 4: add an entry for cygwin: "TERM cygwin" Step 5: copy-n-paste all your customizations from the old .dircolors file into the new one. --- If SO: keep on askin' about this because I have no idea what the trouble might be. ;-P --- Final step: do `eval dircolors ~/[your colors file name here]'. The try it out and see if you have what you want. The dircolors command in Cygwin should, IMHO, output its database with a line containing 'TERM cygwin', and the version I use doesn't do that. I recognize your description of the colors as the default cygwin `ls --colors' output, that's what it does when no LS_COLORS has been provided. HTH, Soren A -- Just say NO to YAHAAPs! (http://groups.google.com/groups?&selm= Xns92991EB1F396ngrATT586ID%40204.127.36.1) -- 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: Viruses being transported with Cygwin messages
"Schaible, Jörg" <[EMAIL PROTECTED]> wrote around 14 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Even more interesting: I have different mail addresses for the Cygwin > list, depending wether I am at the office or at home. My home address > is registered by gmane.org and I received that faked email at home! So > I assume, someone is grabbing addresses from there ... This is OT but important enough to mention once at least. You say you are using Gmane at home. Are you *posting* to this List from Gmane, and if so are you using 'Archive: encrypt' as a custom header in your newsreader settings? If not you may be leaving yourself open to spamming and address harvesting. Pls go to Gmane and read FAQs about how to practice safe "Gmane'ing". HTH, Soren A -- Just say NO to YAHAAPs! (http://groups.google.com/groups?&selm= Xns92991EB1F396ngrATT586ID%40204.127.36.1) -- 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: netinet/in.h and solution for `_impure_ptr' problems
skyper <[EMAIL PROTECTED]> wrote around 15 Oct 2002 news:20021015175423.GN9066@;segfault.net: > now to my short question: what happened to netinet/in.h? > And what happened to cygwin/in.h? > crypto.c:4: netinet/in.h: No such file or directory Nothing "happened" to anything. You see, the trouble you are running into is because you don't understand yet what "-mno-cygwin" is for or does. The limited inclusion of MinGW project pieces (see the MinGW package description) into Cygwin, which is made available for access on the level of Cygwin's build-tools (gcc) automation by "-mno-cygwin", is NOT Cygwin, it is a separate, different build and runtime environment. MinGW != Cygwin. Why would you expect MinGW to have Cygwin's headers? How could that work if MinGW != Cygwin? Why would MinGW exist if it was identical to Cygwin? Why would Cygwin exist if it was identical to MinGW? Asking these questions of yourself will be the first steps towards Cygwin Wisdom for you, Grasshopper. Further questions relating to what MinGW has or does not have are probably OT for this ng, I should add. Therefore I recommend considering carefully whether you'd want to follow-up this posting with responses that ask about MinGW, before you hit the "send" command. Best, Soren A -- Just say NO to YAHAAPs! (http://groups.google.com/groups?&selm= Xns92991EB1F396ngrATT586ID%40204.127.36.1) -- 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: New cygwin & .dir_colors
Igor Pechtchanski <[EMAIL PROTECTED]> wrote around 16 Oct 2002 news:Pine.GSO.4.44.0210161304370.6818-20@;slinky.cs.nyu.edu: >> Sounds like an argument for a patch. Care to submit one? >> >> Larry > > I do (attached). :-D Good going! Soren A -- Just say NO to YAHAAPs! (http://groups.google.com/groups?&selm= Xns92991EB1F396ngrATT586ID%40204.127.36.1) -- 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: export CYGWIN=tty
Randall R Schulz <[EMAIL PROTECTED]> wrote in news:5.1.0.14.2.20021029073133.01fe3b00@;pop3.cris.com: > Also note we're trying to encourage people to put their "cygcheck" > output into an attachment so when others search the list archives they > don't get spurious hits from all the package and library names > included in the cygcheck output. I didn't know that, what a useful strategy. Yes, it will make a significant difference. Thanks for mentioning. Soren A -- 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/
Anyone w/ interest in groff-1.18 port?
Hello, The Subject basically says what I am posting about: I am using this posting to try to cast a seine (sp?) to see if I can snag anybody's attention, who might be working on (or just thinking about working on) porting groff-1.18 to Cygwin. "1.1.7.2-1" seems to be the most recent release of groff as a Cygwin standard package. 'groff-1.18.1' is the latest Gnu release. groff-1.18 offers ANSI color, possibly a very cool advancement to have for viewing manpages. "Inquiring minds want to know... [?]" Thanks, Soren A -- 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: looking for script - make typescript of terminal session
Efi Fogel <[EMAIL PROTECTED]> wrote in news:3DB9A957.10802@;post.tau.ac.il: > I'm looking for 'script', the utility that makes a typescript of > everything printed on a terminal. > > I couldn't find it in any one of the cygwin packages. Have I missed it? Yes, you did: not long ago, on Sept 27, a poster announced it: > From: Alan Evans <[EMAIL PROTECTED]> > Subject: Cygwin port of the Unix 'script' utility. > Date: Fri, 27 Sep 2002 11:01:06 - 0700 > Lines: 369 > Message-ID: <[EMAIL PROTECTED]> > Is it available somewhere else? Is there something similar? Now you can build it yourself, but there are a few errors or omissions in Alan's code and build instructions, which I haven't had time to inform him of yet. Basically check to make sure you have the cygwin inetutils package installed because parts of that are prerequisite for 'script'. Also look for #includes in the top of his C file that are not needed. And so on. I've used Alan's port a little and it seems to work perfectly, once I had ironed out a couple of these build-time wrinkles. Thanks again, Alan. HTH. Soren A -- 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/
Where it runs or what it Does?? (RFC)
[posted today to [EMAIL PROTECTED]; posted to [EMAIL PROTECTED]
(via Gmane) in order to try to get Cygwin's worthies in the loop].
---
[[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)
--
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: Notice of intention to release Perl module specific to Cygwin
On Tue, 12 Nov 2002 21:08:08 GMT, "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote in news:8-1996164353.20021112220808@;familiehaase.de: Soren: >> on Cygwin, there is always going to be more than one >> canonical-ly-correct way to refer to a file by path name (!!): > [...] > >> 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? > > If you like, why not introduce a namespace CYGWIN:: or Cygwin::, e.g. > there are several modules you didn't mention which are supposed to run > *for* or *with* a specific application like Apache:: or XMail:: or > PLP:: or YAML::, so why not introduce the namespace Cygwin:: (if you > look at Cygwin like just another application). > > I would be perfectly happy with a Cygwin:: namespace! Gerrit, as you've seen now if you've been keeping up with replies on the module-authors List (which I think you have), there's some feeling expressed so far against that. On the balance, unless and until someone else checks in with a cogent and authoritative proposal to the contrary (and the comment about File::Spec:: wasn't completely off the mark but it doesn't fit, IMO), I think a second-level namespace is going to win the project more friends and support in the Perl community. In no way does that mean that someone (me, or not me) could not add (or argue for adding) a Cygwin:: module down the road. I just don't see my module as needing that kind of "big umbrella" to sit under. BTW, glitches permitting, I am going to be uploading v0.03 to my CPAN space (SOMIAN in the Authors index) tonight. I think this is the good one, the first real serious grown-up release that's actually ready to be used a little for some actual work (please don't try to design guided-missile controls around it though, I beg of one and all). Filesys-CygwinPaths-0.03.tar.gz. Cygwin-perl users, meet your new friend. Best, Soren A -- 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: No subjects are nice
[cgf, please don't read this. I can't easily send email privately to this bloke tonight or I'd do this off-list. last contrib. by me to this thread] On Wed, 13 Nov 2002 23:35:49 GMT, CBFalconer <[EMAIL PROTECTED]> wrote in news:3DD2E1D5.AEB1557A@;yahoo.com: > It would be much easier if the various lists were echoed to usenet > in the first place. The various Lists are available at Gmane (www.gmane.org). That's how i (mostly) read them now. Advantage: most newsreaders (at least a good / great one like Xnews) present the threaded discussions in a clear, intuitive manner that many email UAs lack. The entire collection of articles going back until the day Gmane subscribed to Cygwin is available for searching and browsing. So what you are asking for is materially achieved already. I personally have mentioned Gmane so many times on this List that i am getting a bit surprised that people aren't getting the message. FWIW, I myself am opposed to the idea of mirroring this list on USENET. The spam harvesters would have a field day and i don't want my address and those of my busy, productive friends (like Gerrit, Chuck and Chris et al) being abused by those creeps to any greater extent than they already are. It's just not worth it IMO. Regards, Soren A -- 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: patch(1) (Win32) and path separators
Parish <[EMAIL PROTECTED]> wrote around 19 Nov 2002
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
>> Try 'patch -p0 --dry-run < filename'.
>
> That did it. Thanks Igor :-)
>
> I'd always assumed that without -p patch obeyed the path in the diff and
> that -p was only needed if, for example, the path in the diff was
> absolute and you needed a relative one. I didn't read all of the -p
> section in the manpage because it didn't seem to be what I needed, but
> /now/ I've read the last paragraph.
I don't always use a tool like patch frequently enough to remember such
subtleties, myself. This was a helpful exchange because I was struggling
with this just yesterday.
{snippo}
> Thanks again for the help.
Yes, thanks!
> Regards,
>
> Parish (who's going to make 'patch' an alias for 'patch -p0' ;-) )
Me too ;-)
Soren A
--
Yes, it's really Sören, not 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/
The Black Art of DLL Creation (revisited)
Is it a science, or an art? [The following description pertains to the *July 2002* version of dlltool]. I am wanting to know about something relating to building of DLLs on Cygwin using the GNU Binutils tools. Up until this point I've been happy enough just letting recent GCC (ld) versions work their magick with the -shared switch, but my recent experimentation (described below) led me to re-visit the venerable (and deprecated, and despised?) "dlltool". This message is really a long-delayed re-taking-up of questions I had responded to by (mainly) Charles Wilson in the past two or three years. The scenario is that I am trying to re-create the process of building bleadperl (experimental branch Perl [5.9.0] from the ActiveState-hosted [canonical] host location). But it doesn't really matter that it is perl -- it could be anything. That it is Perl is not of the essence. But anyway, I want the building of Perl to be conducted the way *I* think is rational. Taking apart the current build setup, we see that dlltool (through dllwrap) is invoked for building the shared Perl library (the bulk of the guts of perl on Cygwin and Win32 generally, is placed into a DLL; the executable is only ca. 50KB in size and acts as a mere "invoker"). It is well known that the functionality to directly create a DLL from object modules has been part of GCC(ld) for quite a long time now, but one thing that you can get from using dlltool, that you don't (I think?) get from using 'gcc -shared' is a .DEF file that is basically correct. If you ask 'gcc -shared' for a .DEF output using the appropriate switches, you get included stuff like a .bss[data?] that isn't supposed to be exported. Anyway, some opinions would hold that the current way Perl is built on Cygwin is an anachronism and is begging to be updated. Dllwrap takes much longer on my system to create the DLL than invoking 'gcc -shared' does, for one thing. BUT, I would like (for reasons that may not seem important to others) to have a valid (by which I mean 'containing all symbols [functions and global data] that need to be exported [visible to external exes] by the DLL, and none that do not') .DEF file to work with. (OK, one reason is that I am interested in the internals of Perl, and examining the contents of the .DEF file gives a glimpse into those internals). So I ran some experiments. I used a command (in the Makefile) like this, to generate a .DEF file: dlltool --kill-at -z [mylibbasename].def [objfiles1] [objfiles2] [...] And I then invoked (in the next step) GCC like so: gcc -shared [objfiles1] [objfiles2] [...] [mylibbasename].def Observations on what happened: 1. The .DEF output by dlltool isn't acceptable to ld(1). It dumps core. The problem is the first line of the .DEF file generated by dlltool. This first line is commented and is a record of the invocation used to create the .DEF. 2. Only a handful of symbols were listed under EXPORTS. These symbols were all prefixed "XS_[foo]" and it is possible, based on my examination of the source, that these functions were declared in some way that doesn't involve "__declspec(dllexport)". The dozens of other symbols that one expects and needs to see weren't exported. 3. The -k (--kill-at) switch did nothing. Ordinals were still being postpended to each symbol's entry. Fixing (1) and (3) was accomplished by post-processing the .DEF file using sed(1). The resulting .DEF file was acceptable to ld(1) ['gcc -shared'] but there was still the problem of (2) unresolved. I made sure that the Perl macros "EXT" and "cEXT" (constant) etc. were being properly substituted with "__declspec(dllexport)". The header in the cygwin/ subdir of the Perl src tree causes it NOT to be set, -- Gerrit and others who are knowledgeable about CygwinPerl may note this -- but I found a way to override that. Backing up: in theory TTBOMU, if I've thus marked a symbol for export this way, the Cygwin port of GNU ld(1) *should* export it unconditionally. Furthermore, TTBOMU, this SHOULD only be necessary for global variables (data) in the first place -- all *functions* should be exported anyway(?). In cases where the src package has no provisions for this, we've used the "--export-all" switch (for either dlltool OR 'gcc -shared') to cause eveything but the special Cygwin excluded symbols relating to entry points, etc. to be marked for export in the final DLL. This is what the CygwinPerl build setup does at present, and I don't understand why. The mechanism for marking symbols with "__declspec(dll[ex|in]port" is already part of Perl src. Why can't we use it? Clearly *somebody* does or did -- probably MSVC does. So my primary question is now, is it documented behavior for dlltool(1) to ignore "__declspec(dllexport)" when creating a list of symbols for export (which it writes out to a .DEF file)? If not, is it broken now? If so, WHY? BTW, I ran these tests using the *J
Re: USER environment variable mystery
Steve Núñez <[EMAIL PROTECTED]> wrote around 22 Nov 2002 5.2.0.9.0.20021123115631.00ad1780@localhost:">news:5.2.0.9.0.20021123115631.00ad1780@localhost: > Does anyone know how to *really* change the environment variables? You have the wrong env variable. Try setting USERNAME *in cygwin.bat* (how can you expect to lie to Cygwin about who you are once you've logged in? -- there may be some way to do it but at first glance it doesn't sound logical). See if that works for you. Soren A -- Yes, it's really Sören, not 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: The Black Art of DLL Creation (revisited)
A brief update. Partial replies to Gerritt. Self-corrections. Soren A <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > The scenario is that I am trying to re-create the process of building > bleadperl [...] but one thing that > you can get from using dlltool, that you don't (I think?) get from > using 'gcc -shared' is a .DEF file that is basically correct. If you > ask 'gcc -shared' for a .DEF output using the appropriate switches, > you get included stuff like a .bss[data?] that isn't supposed to be > exported. OK, I see that this had been fixed in the interim. No longer any need at all to use dlltool explicitly unless we need a .exp file (and why would we? I do not in fact know). > I would like (for reasons that may not seem important to others) to > have a valid (by which I mean 'containing all symbols [functions and > global data] that need to be exported [visible to external exes] by > the DLL, and none that do not') .DEF file to work with. (OK, one > reason is that I am interested in the internals of Perl, and examining > the contents of the .DEF file gives a glimpse into those internals). > 2. Only a handful of symbols were listed under EXPORTS. These > symbols were all prefixed "XS_[foo]" and it is possible, based on my > examination of the source, that these functions were declared in > some way that doesn't involve "__declspec(dllexport)". The > dozens of other symbols that one expects and needs to see weren't > exported. [...] > I made sure that the Perl macros "EXT" and "cEXT" (constant) etc. were > being properly substituted with "__declspec(dllexport)". The header in > the cygwin/ subdir of the Perl src tree causes it NOT to be set, -- > Gerrit and others who are knowledgeable about CygwinPerl may note this > -- but I found a way to override that. Actually I didn't. I hoped that I had and believed that I had, but it was NOT working. I had to learn more about cpp through trial-and-error experimentation and using some tricks, in order to detect this and control it. > Backing up: in theory TTBOMU, if I've thus marked a symbol for export > this way, the Cygwin port of GNU ld(1) *should* export it > unconditionally. Furthermore, TTBOMU, this SHOULD only be necessary > for global variables (data) in the first place -- all *functions* > should be exported anyway(?). In cases where the src package has no > provisions for this, we've used the "--export-all" switch (for either > dlltool OR 'gcc -shared') to cause eveything but the special Cygwin > excluded symbols relating to entry points, etc. to be marked for > export in the final DLL. This is what the CygwinPerl build setup does > at present, and I don't understand why. The mechanism for marking > symbols with "__declspec(dll[ex|in]port" is already part of Perl src. > Why can't we use it? Clearly *somebody* does or did -- probably MSVC > does. I forced the symbols to be marked for export. So, anyway, I was wrong about this behavior on the part of dlltool and ld. I have built the DLL and linked in the Perl executable with some manipulation of which symbols get exported from the DLL, by using `nm' and friends to examine the exports closely. The current setup I have is that I can either choose to generate a .DEF file, or not, and link using the file, or not. There is some difference between what gets exported between those two cases. I'd be happy to discuss that if anyone who is knowledgeable, is interested. I can also control (with approaches that i haven't written about in this thread) the names of the generated libraries (all flavors: DLL [which is really an executable instea dof a classic library], interface lib, and static archive lib. I'v got a massively strange and interesting (to me alone, probably) experiment going here. Best, Soren A -- What do Internet Mailing Lists and crowded neighborhoods have in common? Both will either drive you out or teach you how to ignore barking dogs. -- 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: accessing cygwin functions from non-cygwin app
"Jan Beulich" <[EMAIL PROTECTED]> wrote around 26 Nov 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > All I intended was translating a coupld of filenames from cygwin to > Win32 notation in an otherwise Win32-only app. I quickly realized that > cygwin1.dll does not do all the necessary initialization on its own, > i.e. from DllMain. Instead it appears that I am expected to explicitly > call one or more functions inside the DLL to perform > this initialization. However, whatever I tried (dll_crt0, dll_dllcrt0) > didn't work (i.e. crashed due to insufficient prior initialization), > but cygwin_attach_dll is neither exported from the DLL nor would it, > from its use inside the sources, appear to be meant for the case I'm > dealing with (where a main executaböle directly attaches to > cygwin1.dll). And even if this is the function to use, then I have a > problem using it as the application cannot be expected to have access > to the perprocess class (nor is the app a C++ app, and neither is it > being built with gcc) or other cygwin sources, and it also cannot link > against libcygwin.a. I don't understand most of this, but I thought I'd just mention that I found using the Cygwin API to get converted pathnames pretty simple and straightforward to do, when I wrote the Cygwin Perl module I posted about a while back. It "just worked". It links against libcygwin.a. I am guessing that foregoing meant that the o.p. is trying to call cygwin functions using that MS equivalent of the dlopen() if I am not still totally in the dark. (whatitcalled). Bet that didn't help, Soren A -- Yes, it's really Sören, not 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/
bash isn't running my .bashrc!
Actually, my .bashrc is running fine. The Subject: was a honeypot strategy. AFAICT by reading the Fine Documentation for bash, an *interactive* shell (one invoked with the option flag "-i") does *not* automatically cause the initialization to include source'ing of .bashrc in the user $HOME dir. I have gotten the impression that some people think it does. In order to get one's .bashrc to be included in shell initialization, one needs (TTBOMK) to explicitly tell bash to do it. This directive should be at the end of either one's /etc/profile file or in a later ~/.profile (or the alternate name ~/.bash_profile), depending on whether one uses the latter or not. --8<--- if [[ $- == *i* ]] ; then [ -s ~/.bashrc ] && . ~/.bashrc || echo 'No ~/.bashrc!' fi --8<--- HTH. -- Yes, it's really Sören, not 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: bash isn't running my .bashrc!
Donna and Matthew Persico <[EMAIL PROTECTED]> wrote around 27 Nov 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Probably because many folks have used/are using Korn shell where if, I > think, you do > > export ENV=~/.kshrc > > then ~/.kshrc is run at each invocation, interactive or not, login or > not. > > I think. I kind of doubt it, myself. People who know enough about *nixy shells to know a special env var to set for ksh to get this behavior (and BTW an equivalent exists for bash) are not the folks who are having trouble with THIS kind of thing, IMBG [In My Best Guess]. I think it is mostly people coming from an MSWindows background, maybe never used Linux, who are likely to misunderstand. > So, what made you decide to post this? Scanning recent articles posted to this List. Recollection of past experiences. Long-put-off decision to offer this info. Just because, basically. I do Cygwin stuff in little bursts in the middle of other things, and sometimes I think "I should post something about that" but then cannot get around to it for 6 months or something. Happens. I felt that bash documentation I read in the past was unclear on this point -- didn't read in an easy to understand way. The heuristic bash uses (sorry Mr. Ramey) to decide what initialization files to source is IMO not simple and clear for new users to grasp. It is quite baroque. I've said before and will say again that I know cgf thinks this sort of discussion is OT for Cygwin. By deciding so, he is basically saying "the first thing that some new Cygwin users will grapple with, the unfamililar bash shell, is something we won't offer them any help with." IMHO that's a bit too rigid and demanding: "You either have to have been a bash user already or come to this List understanding that you are expected to find and read an entire bash manual beforehand." A bit unrealistic IMHO. At the same time I recognize that Chris and others don't want to repeatedly answer the same bash newbie questions here and I wouldn't want to see them have to. That's why I referred to the Subject: as a "honeypot". Hopefully a new user will have at the very least tried to search the archive for a posting that matched his or her distress. I am hoping my posting will "lure" future archive searchers towards this helpful information. I am sure it is very likely that Chris or someone else will take issue, fine, I am content to let cgf have his views but I will keep mine. Best, Soren A -- Yes, it's really Sören, not 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: cygwin's autoconf?
Lapo got me started. "Blame" him ;-)... Charles Wilson <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: >> >> The client machine shouldn't need autotools or the know-how to use >> them, right? > > Not necessarily. If configure.in doesn't have AM_MAINTAINER_MODE, > then the default behavior is for all of the "maintainer rules" to be > active all the time. That means configure searches for automake, > autoconf, etc. and uses them to rebuild the infrastructure if > necessary. Now, even if the maint-mode rules never get invoked, > during *configure* you might get "test" invocations -- and it looks > like those test invocations are failing. Autotools are SO broken, and been for so long. Yeah. This is why I go into hyperrant mode. Lapo, the behavior you expect might be considered reasonable. But the ptb at Autotools Central have decreed that providing some theoretical package maintainer "Joe Blow" with the ability to update his package with one hand on the wheel while eating a sandwich and watching "Attack of the Clones" with 65% of his attention, was more important than preserving that principle (that Autotool Build Configurations should be robust and transparent for the end user, and that as Point One the user won't have to install Autotools herself). AM_MAINTAINER_MODE is the Autotools ptb retroactive bandaid applied instead of recognizing that 'automation' had been allowed to run amok in Autotools and a huge step "backward" needed to be taken. Mostly I think it is the fault of Automake which needed the Autotools structure to be distorted, warped for it to have the 'hooks' it needed in order to work the way it (theoretically) does. The disfiguring of Autoconf, by this unhappy marriage with Automake, is pretty horrific. I commmend you for putting effort into learning Autotools. As Gandalf says at one point, "it isn't comfortable knowledge [the lore of the Rings of Power]". Of course he also says "study not too deeply the arts and devices of the Enemy." Not that any individuals at AutoTools are our "Enemy"; Chuck and others here have in fact got considerable amounts of code they've written in Autotools by now. But I still cannot shake the feeling I am confronted with something warped and a bit malevolent, when I contemplate Autotools. At the very LEAST, something that does what AM_MAINTAINER_MODE causes, should have been the *default* for all autotool'd packages, and only by significant contortions should it have been made possible to cause all that "default" behavior to get activated. But instead it's the other way around, and users are at the mercy of package maintainers' ignorance or awareness of the importance of (at the very MINIMUM) placing AM_MAINTAINER_MODE in their configuration file. Soren A -- What do Internet Mailing Lists and crowded neighborhoods have in common? Both will either drive you out or teach you how to ignore barking dogs. -- 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: cygwin's autoconf?
Robert Collins <[EMAIL PROTECTED]> wrote in 1038820917.2953.13.camel@lifelesswks:">news:1038820917.2953.13.camel@lifelesswks: > On Mon, 2002-12-02 at 11:36, Soren A wrote: >> At the very LEAST, something that does what AM_MAINTAINER_MODE >> causes, should have been the *default* for all autotool'd packages, >> and only by significant contortions should it have been made possible >> to cause all that "default" behavior to get activated. But instead >> it's the other way around, and users are at the mercy of package >> maintainers' ignorance or awareness of the importance of (at the very >> MINIMUM) placing AM_MAINTAINER_MODE in their configuration file. > Soren, please don't rant on the wrong list. Firstly, few people here > are autotool gurus, and thus your erroneous statements may go > uncorrected (see below for the correction). Secondly, this is a CYGWIN > list, not a autotool design philosophy list. I think I shall keep my own counsel WRT to what to post, and where ;-). > AM_MAINTAINER_MODE is dangerous because it can easily lead to > dependency problems when a user patches some autotool file, and then > doesn't run the appropriate autotool to update. So, avoid > AM_MAINTAINER_MODE whenever possible. You are an Autotools guru, Robert. Based on my past surveys of the Autoconf List archives, I have the impression that you may have contributed more code to Autoconf & chums (?) than anyone else in Cygwin. The trouble with Autotools is that more so than any software I have ever encountered, it seems historically (at least up until now) to *demand* that the *user* become a *guru* in order to use it reliably (ESPECIALLY on Cygwin, which is why this disc. is not OT for this List). So the distinction we might make in debate like this, between "users" and "gurus", is a bit articifial or at least problematical and debateable. Nonetheless I have to start by pointing out: what the HECK is a "user" doing patching some Autotool file?!? This big issue affects everyone who uses packages which their creator has build-configured with GNU Autotools. That means base Cygwin itself here, and probably the majority of other official Cygwin packages maintained by the various package maintainers. It means that anyone who who wants for some reason (figuring out how to fix a bug they've encountered, just improving performance somehow, whatever) build from source is affected. So I AM going to use a little bandwidth to delve into some aspects. The point about "users" is this: the theory WAS that a "user" (one who builds the package from source code for installation to their own system, but _that's all_) wouldn't even have to HAVE the intermediate Autotools files for that package. Just the sources themselves (a given) and a and a (and also maybe a , depending). As soon as you start talking about "users" needing to work with intermediate (input) Autotools files (some are: , , ), you are already talking about somebody who isn't a "user" anymore. With the majority of the packages I have messed around with, that were not already ported and part of Cygwin distros (and some that were), I have had to leave the ranks of the "users" category and join the ranks of the "hackers-of-build-conf" in order to succeed. I think that this has been so common an experience for so many people that we forget that the line between "user" and "hacker" ever existed, or why. I assert that this is wrong and needs to be corrected. If the theory was that the "user" doesn't need to have the Autoconf files, then how does it look when the "user" runs ./configure and what gets output is a Makefile that requires *Autotools intermediate files* as prerequisites to build package targets?!? I'll tell you what it looks like: BROKEN-NESS. _It is broken_. If that isn't "broken" then your definition of "broken" and any common-sense one are very much at odds. Before it looks like I am not addressing your point: if you are distributing a patch (say it is probably a unified diff format) that modifies Autotools files (and maybe a bunch of others), then I have to wonder why. OK, so your answer is that something in those Autotools build files is in need of correction. So that the build configuration for the package can be updated (fixed). So the category of persons who is *receiving* your patch is ... WHO? NOT "users", but "hackers". By definition. So by definition a "hacker[-on-the-build-config]" is someone who either has the *full competence and knowledgeability* to be hacking on the build configuration files, or they are not qualified to be in the "hacker" category. By definition. This is th
Re: [ANNOUNCEMENT] Updated cygwin package: rxvt-2.7.9-2
Steve O <[EMAIL PROTECTED]> wrote around 02 Dec 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > rxvt is a terminal program that can be used instead of the windows > command shell. Hi, Steve, Is there _anything_ that can be done about the cursor shape in rxvt? That _od-awful block cursor that obscures the character lying under it drives me nuts. Past messages on this List seemed to indicate in my reading, that this wasn't reconfigurable -- that we are stuck with it. That alone would make me not be infavor of rxvt becoming the default Cygwin terminal --even tho I am using Win98 (part of the time). If there is nothing that can be done at run time, can you suggest a place in the src code for me to start looking at, to change it at build time? Thanks, Soren A P.S. In case it isn't obvious to someone, what I would want to see instead of the block cursor is a flashing underscore-bar (or even a static bar) like in the native Win32 console. -- Yes, it's really Sören, not 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: PATH
Christopher Faylor <[EMAIL PROTECTED]> wrote around 04 Dec 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > On Wed, Dec 04, 2002 at 02:45:17PM -0800, Alan Larkin wrote: >>I have a Makefile.mak which contains the rule >> >>Lexer.c: Lexer.l >> >>(using the implict rule for lexing). When I try making it (by double >>clicking) it complains that make cannot find a rule to make Lexer.l >>needed by Lexer.c. Lexer.l is of course in the working directory but >>it doesnt seem to find it. Ive added .: to the PATH all over the >>place! /home/alan/.bash_profile (which now just looks like >> >>export PATH=$PATH:. > > AFAIK, the PATH isn't used to find files in make. I can conclusively confirm Chris' statement, which was worded a bit tentatively: absolutely, PATH has nothing to do with where GNU 'make' (or any other that I know of) looks for files. Nothing whatsoever. This confusion over the basic concept of what PATH is for has come up before, I can recall. Again, TTBOK there is no (credible) program or software system in existance that uses $PATH (%PATH%) for *anything* except for finding executables to run (including of course DLLs, which in the DozeWorld are considered executables). > Given that you have mixed case in the above example, I'm guessing that you probably have > an incorrect case in the actual filename, i.e., the file is actually > called lExer.L or something like that. If you do this: > > mv lexer.l foo; mv foo Lexer.l > > you may be able to correctly set the filename case. Probably 'make' shouldn't be treating targets on this platform as case- sensitive. But this is a fairly esoteric issue and I don't know right off- hand whether this could be the explanation. If one wanted an authoritative answer then I think the GNU 'make' List would be the place to go (can be read on Gmane BTW: www.gmane.org). My thinking is that I would want to make sure that the cwd is really what you thing it is (OP). It seems possible, if unlikely, that 'make' is actually working in another dir than where the makefile and sources are located? The manner in which you (OP) are starting this process from a shortcut icon is non-standard and might have odd side-effects. BTW, "VPATH" is a mechanism existing in GNU make for explicitly telling make where to look for targets that might need to be remade (prerequisites). Please `info make' (or 'man make'). Soren A -- Yes, it's really Sören, not 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: cygwin's autoconf?
BTW, as serendipity (or synchronicity) would have it, those who read DDJ might have noticed the article about Cmake (http://www.cmake.org/) that appeared in the latest issue. Cmake looks like it might be worth looking into (and yes it is Open Source software). Soren A -- Yes, it's really Sören, not 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: problems with CPAN and cygwin >1.3.12
JoNO ZzZ <[EMAIL PROTECTED]> wrote around 07 Dec 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > CPAN.pm: Going to build > M/MS/MSISK/HTML-TableExtract-1.08.tar.gz > > Checking if your kit is complete... > Looks good > Unable to find a perl 5 (by these names: > /usr/bin/perl.exe perl.exe perl5.exe perl5.8.0.exe miniperl.exe, in these dirs: > /usr/local/bin /usr/bin /bin [... snip] It is a problem in MakeMaker, which CPAN.pm is calling to build the module. It isn't strictly speaking a CPAN.pm problem per se. Try downloading the module package manually (search.cpan.org) and unpacking the targz ball, then cd'ing into the dir thus created. Follow the traditional steps to build and install a Perl module from that point (if you do not know what they are I strongly suggest that you RTFperlM). Does the module build, test and install without hang-up? Please do not forget that all support for all Cygwin packages, such as Perl, is supplied by volunteers on their own time. Beyond the immediacy of your desire to get something working for you, which isn't right now, you will create better karma by manifesting a willingness to go to greater lengths to work out some answers yourself. If you follow the above instructions and still cannot install this module, then get back to "us" (this List), we will all know more than before about what might be wrong. If you leave it to someone else to take these steps you *may* get a "free answer" eventually but you'll have done nothing for your karma in the process. Best, Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: [ANN] cyg-wrapper.sh
Luc Hermitte <[EMAIL PROTECTED]> wrote around 05 Dec 2002 20021206013757.GA976927@ORLYN:">news:20021206013757.GA976927@ORLYN: > cyg-wrapper v2.2 has been uploaded on my web site: > http://hermitte.free.fr/cygwin/#Win32 > http://hermitte.free.fr/cygwin/cyg-wrapper.sh Luc posted on my urging; please check out his site and this script which is a useful and good piece of hackery. > cyg-wrapper is a shell script that helps to run, from cygwin, > command-line applications that have been compiled for windows only ; ie: > applications un-aware and independant of the cygwin layer.[1] > > cyg-wrapper converts pathname arguments, passed to win32 programs, from > the written form (unix/dos/windows ; relative or absolute) to the DOS > (short [2] ; and absolute) form that win32 command-line programs > understand. > > It extends what cygpath do, to every pathname arguments, and resolves > the symbolic links. > > > A typical way of use is for instance: > alias gvim='cyg-wrapper.sh "C:/Progra~1/Edition/vim/vim61/gvim.exe" > -binary-opt=-c,--cmd,-T,-t,--servername,--remote-send,--remote-expr > --fork=1' > that defines the alias 'gvim' which: > - calls the win32 version of Gvim, > - converts every pathname argument (identified as beeing those that do > not begin with '+' or '-', and that do not directly follow '-c', > '--cmd', '-T', ...) > - forks immediately ; which replaces the disabled '-f' option of the > win32 version of gvim. > > > Note: the latest version of cyg-wrapper requires cygUtils and more > precisally realpath. An older but slower version is also available on > my web site. > > Feedback appreciated. I am going to be making cyg-wrapper.sh a part of my bash inifiles, as I discover uses for it. That is, i'll define aliaii like the above example to GVIM, in my ~/.profile or ~/.bashrc. > [1] BTW, Is there a canonical expression to designate such applications ? > I tend to use "native win32 applications/programs", but I'm not sure > it is really correct in English. "Dumb Software" ? ;-). No, the way you wrote it seems proper to me. I don't know of a better widely-understood terminology, but I wish there was one, because this is an issue I deal with a lot. I use a lot of cross-platform software where the application understands a path argument passed to it like this: someunixyapp -flag1 -flagn C:/datafiles/forwardslashed/data.data And I have seen here these kinds of path specs called "mixed" paths, because while they are not POSIX (single-rooted filesystem) they use forward slashes. Yet people commonly refer to many apps that understand these kinds of paths (as does the OS itself, in fact, but not its native shells) as "Native Win32 ports". In this respect there is a further level of "nativeness" (or really, "dumbness") that could be specified, but we have no custom or convenient nomenclature for doing so. > [2] This form has been privileged because of the MsWindows 9x series. Hmmm. If you mean that people who run Win9x are more likely to be running old DOS programs that use 8.3, then ok; otherwise there's no difference between NT-derived and 9x-type Windows in this respect -- that I know of. Best, Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: [ANN] Re: cyg-wrapper.sh
Luc Hermitte <[EMAIL PROTECTED]> wrote around 08 Dec 2002 20021208193753.GA44134983@ORLYN:">news:20021208193753.GA44134983@ORLYN: >> > [2] This form has been privileged because of the MsWindows 9x >> > series. >> >> Hmmm. If you mean that people who run Win9x are more likely to be >> running old DOS programs that use 8.3, then ok; otherwise there's no >> difference between NT-derived and 9x-type Windows in this respect -- >> that I know of. > > No. This is a scripting problem I had on MsWindows Me, and I don't > remember any similar issue on Windows NT -- more tests should be done to > be sure. > > The problem comes from pathnames having spaces. If we want to run: > appl "c:/Program Files/foo.txt" ~/bar.txt > The parameters should be requoted before (/while ?) running xargs. I > haven't spent enough time to find to something that works. Yes. I am pretty sure that you'll have the same problem with pathnames containing spaces on NT & its derivatives, too. So having the wrapper generate the 8.3 form of the name probably isn't a bad idea, at least as far as this issue goes. There might be other (side) effects. Not to seem like I am competing with you or upstaging you, Luc, but I want to announce (bec. I am assuming the readers of this thread might have interest) that I have done my own WWW publication about how I start (instantiate) GVIM from Cygwin's bash shell: http://home.att.net/~perlspinr/vim/VIMhelpers.html It doesn't use your cyg-wrapper script because I wanted to do some more elaborate stuff. Readers "shopping" for a test editor to use in conjunction with Cygwin are encouraged to check out GVIM 6.x (www.vim.org) -- it rocks. And then use my script to run it from bash ;-). Best, Soren -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: /tmp
Shankar Unni <[EMAIL PROTECTED]> wrote around 10 Dec 2002 at5bsm$9qn$[EMAIL PROTECTED]:">news:at5bsm$9qn$[EMAIL PROTECTED]: > (The reason is because I use a *native* tcsh as my shell, which has > some NT-specific extensions for filename completion > (complete=igncase), titlebar setting, etc. But the filename completion > is (naturally) unaware of cygwin mounts, so I was trying to get the > setup to look as much like the native structure as possible, while > allowing things like "man" to still find their files). > > Anyway, I've given up that idea, and just deal with the mental bump > when doing filename completion of something in the cygwin tree. The > command line does one thing, and "ls" does another... This is interesting. You are the second person in the last three weeks who has talked about using this native tcsh shell (the other was off-List). I sure wouldn't find it worthwhile to use a different shell (that doesn't understand what Cygwin has to do with mounts, and so on), but if there's one thing I've learned, its that you can nenver tell another person what they should like in a shell. Each to his own. Soren A -- "Work like you don't need the money. Love like you've never been hurt. Dance like no one is watching." -- unknown -- 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: rxvt customization questions
On Thu, 19 Dec 2002 12:09:09 GMT, [mn] <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > > I've got some questions concerning the latest Cygwin version of rxvt. > > First, I played around with the .Xdefaults file a bit. I, also, would welcome any discussion of how rxvt works on Cygwin. I just recently began using rxvt after a long period of resisting (I invested a great deal of time and effort into learning how make the native Windows console work optimally with bash). the one thing that really pleased me was when i discovered in a marathon late-night Googling session, with considerable effort to interpret poorly- written documentation, how to clear the entire rxvt console buffer and go back to (0,0): echo -ne '\033c' thus one can alias: alias cls="echo -ne '\033c'" TIA, Soren A -- 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/
retval of pipelined cmd in bash
Hallo Cygwains,
[Heck, I dunno... "Cygwinauts"?].
I have a possibly OT question, that is, a bash shell question. Lacking
the insight into the deepest reaches of shell-ology, I have come up
empty on all attempts to solve this one for myself. (Those attempts have
included doing `info bash' and reading the "Advanced Bash Scripting
Guide", an excellent resource available on the Web).
I am writing a shell script that chains together several commands in a
pipeline -- very *nix-ish. The first command in the pipeline is an
invocation of `make'. Here's the entire script code -- I've tried many
very elaborate or bizarre things, before this:
--8<---
function powermake
{
declare -x LESS='-z-2$ -s~wR'
declare PAGER='/bin/less'
declare +x ECODE=
{ make "$@" || ECODE=$? ; } 2>&1 | tee $MAKE_ERR_TO | \
/cdv/f/scr/colormake.pl | $PAGER -O"${MAKE_ERR_TO}.colorlog"
if [[ $ECODE ]] # "0" and "1" are both TRUE; "null" is FALSE.
then $gvimexe --servername 'QUICKFIX' -q "$(cygpath -wla $MAKE_ERR_TO)"
else echo 'No "make" errors to diagnose: retval was ' '"'$ECODE'".'
fi
return $ECODE
}
--8<---
The problem I am trying to solve is how to get the return value of the
`make' tool. If there was an error I need to know about it. But as it
stands, nothing that i have tried will cause me to see the VIM editor
session start up; the value in ECODE is apparently always "0".
Does anyone know how to do this -- how to pull out a return value from a
command in the middle of a pipeline?
Thanks,
Soren
--
Yes, it's really Sören, not 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: Perl package File::Spec confused under cygwin
On Fri, 20 Dec 2002 21:27:50 GMT, "linda w \(cyg\)" <[EMAIL PROTECTED]> wrote in 001b01c2a86e$a5da95f0$[EMAIL PROTECTED]:">news:001b01c2a86e$a5da95f0$[EMAIL PROTECTED]: > File::Spec is supposed to provide a OS independent way of parsing and > creating pathnames. For example, a 'splitpath' can product a volume > $dir and $file. > > I'm not sure what constitutes a volume but I'd think C: D: would count > as separate. > > Under cygwin, it only handles/parses unix pathnames but not native > windows pathnames 'c:\windows\filename' will yield a vol='', dir='' and > filename='d:\windows\filelname' -- not what one would expect. Using > forward slashes yields: vdf='', 'd:/windows/,'filename'. > > Further use to break down the directory path into components would > yield D: as a first directory and 'windows' as a 2nd level dir. > Note that the forward slash has now disappeared indicating what I believe > to be improper symantics as d:windows != D:\windows unless d:'s curdir > is = to the root dir. By this point, you are looking WAY to hard in the wrong direction. > Guess when the module detects the OS type, it needs to have a separate > type for the cygwin environment. Linda, This is why I wrote a module specific to Cygwin and how it handles pathels (path elELEMENTs) and file specs. Or doesn't. What you expected File::Spec to do perhaps seemed intuitive and natural, but in fact the situation on Cygwin is kind of unprecedented and no, Perl hasn't been "ported" to Cygwin to THAT degree. The fact is it is a pretty complex set of issues. First of all, the $^O (Eng: $OS_NAME) on CygwinPerl is *not* 'MSWin32'. You need to be clear on that because if you rtfm the File::Spec module you'll see that it matters. The value of $^O on Cygwin is "cygwin". Because Cygwin perl is not Win32 perl, it is a hardly-changed vanilla Unix Perl. On Cygwin we have a possibility to access files on the local filesystem (as distinguished from any sort of "remoteness") via two different "modes": the correct "cygwin" mode which is otherwise knows as the POSIX filesystem; and the completely different Win32 mode. Never the twain shall meet. They are fundamentally incompatible, as a little thought will show to anyone who ponders it (and many have). The module I wrote, which is in existence as a pre-release on CPAN but hasn't been officially Registered in its namespace, is Filesys::CygwinPaths. Look in the Authors directory of CPAN under my CPAN id, SOMIAN, or search on search.cpan.org (new pre-releases have shown up in the daily roundup, to my surprise). If you go back and rtfm on File::Spec and still cannot get the tools you are looking to get, then my module almost undoubtedly addresses your need. Whether you'll enjoy using it or find it pretty is another question entirely. Regards, Soren A -- Yes, it's really Sören, not 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: Perl package File::Spec confused under cygwin
On Sun, 22 Dec 2002 02:59:49 GMT, Michael A Chase <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > On Sat, 21 Dec 2002 17:36:58 -0800 "linda w (cyg)" <[EMAIL PROTECTED]> > wrote: > >>> Note that Cygwin, like Unix, doesn't have a concept of >>> volume. Everything except network paths (//host/dir) are >>> based on a single root directory. >> --- >> But Unix does have a concept of a mount point (device) and >> path from the mount point. Conceivably, one could view the >> mount point itself as a local host name for the "volume" (local, >> remote or a device) with path being location on the mounted fs. > > device != volume. For the purposes of File::Spec, it would be better > to leave the directory structure as a single tree. > >> It is arbitrary to choose to see the /fs as one giant >> undifferentiated tree. > > But that is the convention used by Unix and hence Cygwin. You can > distinguish which device a file or directory is in by using the first > element returned by stat(), but that doesn't affect the file spec. This is the crucial point. It may be arbitrary but that doesn't mean you can ignore it and still make cogent arguments that some code isn't working right. Historical factors determine a great many things in our computing life. Historically, MS Windows decided to have a concept of "Volumes" (which indeed are NOT the same thing as "devices") whereas Unix decided to have such a thing as a single-rooted or monolithic filesystem. That's just the way it is. I personally think that the single-rooted filesystem is far more rational. Take away the conventions that dictate that there will always be a "/bin" and a "/usr" and a "/tmp" dir, etc., and it is *still* an important concept. There's always going to be a "root" above which you cannot climb, but beneath which everything can be decended into. To me, that is rational. Also more than any other single factor it gives me the kind of distinct Unix-style computing experience. It reminds me that the family of orchid plants (a huge family numbering in the 10s of 1000s of species) there is a major division: "monopodial" ['single-footed'] vs. "sympodial" ['together-footed' or something like that]. At a glance, most people can see the difference between monopodial types of orchids and sympodial types, once the concept has been explained to them. Likewise, this filesystem-structure difference between MSWin and POSIX is a BIG, fundamental difference. It isn't merely a small detail of style (that people can be careless about paying attention to most of the time) but rather a large, shaping issue. IMHO. >>> You can always call File::Spec::Win32 -> splitpath() to get >>> that behavior. >> --- >> Well, for 'portability' one shouldn't call :: anything. >> The purpose of File::Spec was to provide a OS independent way to >> deconstruct/construct pathnames into their separate components. > > Portability is a worthy goal, but sometimes you have to accomodate > your specific environment, that's why $^O is available. Yeah. Sometimes the better part of valor is just to put some conditionals in your Perl code to accomodate the reality that Perl hasn't yet been able to completely "flatten" all OS distinctions. >>> It does, but File::Spec::Cygwin is very close to File::Spec::Unix. >> --- >> Yeah...got that. I guess most immediate fix would be to fix >> the Cygwin version to differentiate things... then if it was >> important, one could split the path to mount:path for more useful, >> yet spec-compatible functionality. > > If you submit a Perl bug report with a patch that does what you want > and explains why you want it, it is likely to get included in the next > release of Perl. If you talk nice to Gerrit, you may even get it in > the next build of Cygwin Perl pending a change to the base source. > Borrowed code from File/Spec/Win32.pm may provide a start. I am wondering, Michael, have you tried my module? I'd value your feedback on it. CPAN-Authors listing: /S/SO/SOMIAN/. -- Yes, it's really Sören, not 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: DOS <-> Bash interaction...
Igor Pechtchanski <[EMAIL PROTECTED]> wrote around 28 Jan 2003 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > If you get something different as the first entry, your /etc/profile does > *append* the standard paths to the contents of $PATH. This means you've > probably changed it at some point in the past. Change it back. Right. And yes, I have read the rest of the articles in the thread, but found that one question gets left behind immediately, in the course of running down the PATH issue: that was, the very top issue Hannu raised, which is "what does $SHELL contain"? I am wondering what Cygwin does by default -- I have been using highly modified bash initialization files for a very long time now and so I cannot find out by merely going and looking at my own. Do any of the init files that bash reads set, query or export SHELL? Would it be a good idea for them to do so? It seems to me that when I set up Cygwin (my installation on Win98SE thereof, that is), I had to set SHELL and export it, in my bash init file, when I worked on achieving good integration with the editor GVIM (the Win32 GUI version of the VIM editor). This memory-impression suggests that Cygwin isn't exporting SHELL by default. Confirm or denials, anyone? ;-) I actually have 3 "choices" of SHELL on this Win98 box, because I've installed a partly-functioning CMD.exe from a Win2K SDK release by M$. So I have available a command.com, a CMD.exe, and a bash.exe. I *always* want to be using the bash.exe in connection with any Cygwin stuff I am doing, but in the past have wanted CMD.exe, for instance, in connection with other things (MinGW-ish, but that's OT here...). Almost never do I intentionally want command.com, of course. This is all rhetorical and general-interest for me personally, since I already have Cygwin doing what I want it to in these areas. I am not calling for a change of any specific sort, just asking for discussion for the purposes of increasing general understanding. Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: Save typing /cygdrive/c?
"Max Bowsher" <[EMAIL PROTECTED]> wrote around 27 Jan 2003 000701c2c643$25729550$78d96f83@pomello:">news:000701c2c643$25729550$78d96f83@pomello: > Rob Siklos wrote: >> running "mount --change-cygdrive-prefix /" will make all your drives >> be subdirectories of "/" instead of "/cygdrive". > And then when you run some script which expects /cygdrive, it will > break. OK, the script is what is broken, but the path of least > resistance is to use symlinks instead. Such a script would indeed be broken, and if I found such a one on my system I'd delete it immediately, no matter how important it thinks itself to be. I get the point about path of least resistance but won't go along with it in this case. Cygwin has never fetish-ized (fixed as canonical, forced) the "cygdrive" string, TTBOMK, and I hope it doesn't become so. I myself use the much shorter string "cdv" (as in "/cdv/e/stuff") which is mnemonic with "cYGdRIVEvOLUME". I even wrote a Java class to query Cygwin for this information in order to use the Sun JDK Java rt product with Cygwin's shell environment. IMHO, correct programming (of all sorts) for Cygwin should always be using programmatical (documented API) means of composing path strings, not hard-coding (ASSuming) a particular path prefix to the drive volumes. Not In The Least Opionatedly Yours, Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: Save typing /cygdrive/c?
Igor Pechtchanski <[EMAIL PROTECTED]> wrote around 27 Jan 2003 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Scott, > > "mount" is part of the "cygwin" package, so it should work if you've > installed Cygwin. "man mount" is another story, however. A search for > "man1/mount.1" on <http://cygwin.com/packages/> reveals that you need the > "cygwin-doc" package. Sorry for my assumption that it is installed > automatically. I think it might be worth pointing out that 'info' is the newer and more-supported GNU help system, too, and if `man FOOdo' ever fails, the user should automatically think "Oh, let's try `info FOOdo' too" before getting upset or stressed over her inability to get instantaneous help on "FOOdo". Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: cygwin path problems
Randall R Schulz <[EMAIL PROTECTED]> wrote around 27 Jan 2003 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Note, too, that if you have a classpath variable in POSIX format > (colons and no drive letters), you'll need to use something like > "$(cygpath -pm "$POSIXCLASSPATH")" to convert it. > > > Only (_only_) Cygwin-linked code will understand the "/cygdrive/..." > file names. And also note that if you are trying to use (bash/posix-unixy) shell *wildcards* [ ;-) ] to pass filenames as _arguments_ to your Java class (program), you need to know that Java will receive them in Cygwin's posix format and won't grok them. The results of a shell expansion like this: /cdv/D/goodies/babe*.jpg IOW, won't be formatted like "/cdv/D/goodies/babe1.jpg:/cdv/D/goodies/babe2.jpg:[...]" but instead just as plain list of space-separated filespecs. AFAIK, `cygpath' cannot help you there (corrections will come as a surprise but are welcome, "cygpath" gurus). Of course a little more elaborate shell-wrapper magic might hack you a way out of that problem, robustness and speed-performance are likely to be lacking, tho. So if you run into this trouble you might want to go download my Java class "CygwinShellInterface", written to translate Cygwin's posix filenames into Win32 ones that Java understands: http://home.att.net/~perlspinr/framesets/cygwininfo_frmset.html Or re-invent that wheel, your choice ;-) Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: SSH and Home
"Kevin Jones" <[EMAIL PROTECTED]> wrote around 27 Jan 2003
000101c2c62d$d84b59c0$0200a8c0@milo:">news:000101c2c62d$d84b59c0$0200a8c0@milo:
> You're absolutely right - I've gone through the process of changing to a
> name with no spaces but the problem persisted. After reading this I
> changed my etc/passwd file so that home was /cygdrive/d/home/kevinj and
> I'm golden
This one bit me too, awhile back when I was first setting up ssh. IMHO
this is a fairly specific, non-obvious case of something happening that
newer Cygwin users won't be looking out for. I mean the "/etc/password"
thing, not the "spaces" thing -- the querying of /etc/passwd that shh is
doing (I've never had spaces in my HOME directory spec, so that part of it
never bit me).
My $HOME is E:/home/[username] in Win32 mode ("/cdv/e/home/[username]"
in Posix mode) and ssh couldn't find it, was barfing, because I had not
edited the /etc/passwd file. Not being a big user of applications in
daemon mode on Cygwin previous to that, I never had it cross my mind
that an app would need to find out where $HOME was by some other means
than querying the current environment. Of course, once it is explained,
it is obvious. I first thought, though, that ssh was broken (as in:
badly ported, buggy).
I still believe that by some means, this issue needs to be brought to
the attention of new (and potential) ssh users IN BIG BOLD PRINT. ;-).
I'd like to see a Cygwin FAQ entry regarding it.
Also Cute and Fluffy,
Soren A
--
"So, tell me, my little one-eyed one, on what poor, pitiful,
defenseless planet has my MONSTROSITY been unleashed?"
- Dr. Jumba, Disney's "Lilo & Stitch"
--
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: DOS <-> Bash interaction...
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote around 28 Jan 2003 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > This issue isn't Cygwin specific, since setting of the SHELL > environament variable is handled by the shell itself. > As such, discussion of this is really off-topic for this list. Cygwin bash is a *port* of GNU bash to _Cygwin_. As I have previously written, this sort of discussion is IMNSHO *totally* ON-topic for Cygwin. There are many potential issues here that wouldn't come into play for bash users on a generic Unix platform. Furthermore, use of bash is assumed for most new users of Cygwin, some of whom will also be using a Unix-ish shell for the very first or nearly the very first time as part of their experiential introduction to Cygwin. If the intent is to exclude such users from Cygwin-usership, somewhat in the way that certain Chem or Physics courses are used (made intentially very difficult to pass) to "weed out" less gifted or prepared students in pre-med-track College programs, then this is a very effective way of doing that. "Don't offer any help with bash, reflexively condemn any raising of such Q's as OT, tell all posters to RTFM rather than discuss the finer points On-List" -- this sounds like a secret strategy and agenda to me. I wonder sometimes when you will tire of endlessly repeating this refrain, Larry. It would take less time to answer such questions (thus getting them into the Cygwin List archives) than the total time you've put into telling other people what to discuss or not to discuss. I myself am not tired of stating my disagreement with this POV and the reasons why. > I found a quick check of the bash man page and searching for > SHELL shed allot of light on the subject however. You might > want to check it out yourself. I think it owuld be a lot more interesting to discuss the manpage here. > I don't set SHELL in any startup files or my Windows environment. > SHELL is always set to /bin/bash for me. OK, but is it exported? There is a difference between a shell variable that is _defined_ and one that is _defined_ and _exported_. A functional difference that matters very much when spawning any sub-processes. Agreeing to disagree, as usual, Soren A -- 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: Save typing /cygdrive/c?
"Max Bowsher" <[EMAIL PROTECTED]> wrote around 28 Jan 2003 01c201c2c714$951686b0$78d96f83@pomello:">news:01c201c2c714$951686b0$78d96f83@pomello: > And it's also worth pointing out that "pinfo" makes info pages viewable. > (The "info" program itself is a nightmare to use.) I suspect that my ignorance will now be showing, but: I just type `info [FooBar]' and the info display of FooBar just comes up. I don't know what 'pinfo' is or why I'd need it. Thanks, Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: Save typing /cygdrive/c?
Robert Citek <[EMAIL PROTECTED]> wrote around 28 Jan 2003 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > At 10:50 PM 1/28/2003 -, Max Bowsher wrote: >>Soren A wrote: >>>I don't know what 'pinfo' is or why I'd need it. >> >>Another info viewer that looks nicer and uses intuitive key bindings >>(lynx-like). Navigating info documents in info is a challenge to say the >>least. > > Keybindings are vi-like. Ahh, vi-like? Now you're talking MY language. Very cool. Yes, thanks, Max. Soren A -- "So, tell me, my little one-eyed one, on what poor, pitiful, defenseless planet has my MONSTROSITY been unleashed?" - Dr. Jumba, Disney's "Lilo & Stitch" -- 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: make etc....
"Simon Whittaker" <[EMAIL PROTECTED]> wrote in news:00b701c25d64$71c03590$[EMAIL PROTECTED]: > > I have tried automake as well but this errors out. > In addition to the sound and informed suggestions in Tim Prince's reply, I will offer you the advice that it read to me as if you don't know for sure what `automake' does. I urge you not to experiment randomly and carelessly with that particular command. Soren A -- 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: libpng not found.
"Krung Saengpole" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> I come to this mailing list for the first time. If I go to the wrong
> place, apologize me. I installed Cygwin on my machine (Win95), when I
> compiled my program that use -lpng, system told me that libpng wasn't
> found. I installed cygwin including libpng. What I did wrong or how to
> solve this problem?
Your message text reading "my application" conveys ambiguous meaning to me.
If you mean that YOU are the AUTHOR of an application that uses libpng then
you need to become sufficiently acquainted with libpng and its issues I
think. I recommend you visit the libpng home site and probably subscribe to
the libpng mailing List ("png-implement"). If you instead mean merely that
"my current task is to build an application that uses libpng, that somebody
else is the author of", then it would be better for starters if you
identified what application you are trying to build. Giving more
information is really usually better if anyone is to provide useful help to
you (and possibly to other future readers as well, who will discover this
dicsussion and use it to solve their own problems, rather than requiring
folks to repeat the same answers again and again).
If you wish to confirm that libpng files do exist on your system there are
several possible avenues to explore. For example you could try
$ find /usr/lib -name '*png*.a'
OR
$ cygcheck libpng
This background information below may help. Or it may not.
As found on my Web page at
http://home.att.net/~perlspinr/IM_build.html
libpng
The development group in charge of libpng has recently had to make changes
to the way libpng's headers (there are two of them) and library archive(s)
are to be placed at install-time on the system. Formerly, in general, the
headers went into the standard Posix system include dir (either
/usr/local/include or /usr/include) and the library was named libpng.dll.a
and placed into the usual library dir (/usr/local/lib or /usr/lib).
Now, the layout for the location of the library archive is like (on Cygwin,
a Posix-overlaying-Win32 system) this (easier to show than to describe):
/lib/libpng10.a
/lib/libpng10.dll.a
/lib/libpng.a -> libpng10.a
/lib/libpng.dll.a -> libpng10.dll.a
The file libpng.dll.a is now merely a symlink to the versioned file (as of
this writing, libpng10.dll.a). This change poses no problem to configure.
The headers are a different story:
/usr/include/libpng10/png.h
/usr/include/libpng10/pngconf.h
Now, the headers are located in a subdirectory of a standard Posix-tree
include dir, named for the "generational release number" (or whatever
we'd call it) of the libpng distribution:
/usr/include/libpngNN/*.h.
The C compiler gcc does not have this subdirectory on its default system
header search path. Thus, the configure script fails at this points to
find a complete and viable libpng installed.
The new introduction of versioning in the installation style was
necessitated by a break in binary compatibility. Please see the libpng
documentation, the libpng home page or the libpng mailing list archives
for more information.
Soren A
--
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: libpng not found.
Shankar Unni <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: > Soren A wrote: >> Your message text reading "my application" conveys ambiguous meaning >> to me. > > [ much detail deleted ] > > Could you maybe have started off by suggesting that he install "libpng" > from the "Libs" section during the setup? Well, now you just did. Perhaps that will help him; my reading of his words >>> I installed cygwin including libpng. took him at face value (or what seems to me to be face value) and I proceeded from there to guess that he most likely knew about neither the 'pkg-config' mechanism nor the 'libpng-config' mechanism for getting the '-I' and '-L .. -l' flags he might be missing in his build setup. Soren A -- 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: How to install packages...
Christopher Faylor <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> We've seen it more than once. People don't understand that the same
> program they used to install cygwin can be used to update their
> installation with new packages.
Chris is correct in this observation.
As far as I could could parse the subsequent articles, there was some
derision expressed inreaction to the idea of updating the main Cygwin
page to clarify this. There shouldn't be derision, IMHO.
*Most* software that MS Windows users get exposed to, that is
distributed as a zip archive and that typically has a file named
"setup.exe" inside that archive, works in such a way that the setup.exe
is _only_ for doing the one-time installation of the program files (and
writing of Registry entries if that is involved, and misc other things
like mangling the machine's autoexec.bat might happen too...). The user
might as well delete it after that (WinZip usually will do so
automatically for it and everything else that was part of the
installation system). Point: It is completely counter-intuitive for *MS
Windows users* (as opposed to those fully initiated into the *nix
priesthood somewhere along the line) to expect to run a "setup.exe"
program more than once (Unless they've reformatted their HD as Windoze
tends to periodically require).
It's always been a little problem that the particular name "setup.exe"
was chosen for the Cygwin installation manager (IMHO). You don't run
"setup" on a Debian GNU/Linux box and you don't run "setup" on a RedHat
Linux box (You run 'apt-get ...' or 'dselect ...' and 'rpm ...'). These
are distinctively-named systems. Lacking ambiguity. 'CINMAN' anyone? It has
a nice, provocative ring to it... ('CIM' was already taken, long ago, in
the days of yore before AOL swallowed the World...)
Of course, it's too late now to do anything about the name of
"setup.exe". *Except* adding an explanation that "you'll use it to
change or update your Cygwin system installation on an ongoing basis"
for the main Cygwin page, right under the "Install Cygwin Now" icon(s)
or close by.
Soren A
--
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: How to install packages...
uot;;>SANFACE Software http://ircd-hybrid.com/";>Hybrid 7rc1 IRCD Jul 29 2002, mailto:[EMAIL PROTECTED]";>Zeke Gomez http://www.shaolinsecureftp.com";>Shaolin Secure FTP v0.98 Beta 3 Jul 4 2002, mailto:[EMAIL PROTECTED]";>Joseph S. Testa II http://www.gnu.org/directory/recode.html";>Recode - character set conversion Jun 25 2002, mailto:[EMAIL PROTECTED]";>Francois Pinard ftp://ftp.imagemagick.org/pub/ImageMagick/binaries/";>ImageMagick 5.4.6 Jun 18 2002, mailto:[EMAIL PROTECTED]";>Bob Friesenhahn http://www.singular.uni-kl.de/";>Singular - A Computer Algebra System for Polynomial Computations May 28 2002, mailto:[EMAIL PROTECTED]";>Viktor Levandovskyy (Singular Team) http://mservice.sdf-eu.org/SocksCleaner-0.4/sockscleaner-0.4-cygwin.tar.gz";> IRC Socks Scanner Sockscleaner 0.4 May 21 2002, mailto:[EMAIL PROTECTED]";>Diego Duarte http://batousai.sdf-eu.org/gmp-4.0.1/gmp-4.0.1-cygwin.tar.gz";> The Gnu GMP 4.0.1 May 21 2002, mailto:[EMAIL PROTECTED]";>Diego Duarte http://mservice.sdf-eu.org/Hybrid-6.3/hybrid-6.3-cygwin-stable.tar.gz";> Hybrid 6.3 IRCD May 21 2002, mailto:[EMAIL PROTECTED]";>Diego Duarte http://batousai.sdf-eu.org/mICQ-0.4.8-pl5/mICQ-0.4.8.pl5-cygwin.tar.gz";> micq 0.4.8 May 19 2002, mailto:[EMAIL PROTECTED]";>Diego Duarte more software announce new software Contact, web page, other info... For Cygwin licensing or commercial support, please visit the http://www.redhat.com/software/tools/cygwin/";>Red Hat Cygwin Product site. For all other questions and observations, please check the resources available at this site, such as the http://cygwin.com/";>FAQ, the http://sources.redhat.com/cygwin/cygwin-ug-net/cygwin-ug-net.html";>User's Guide and the http://cygwin.com/lists.html";>mailing list archives. If you've exhausted these resources then please send email to an http://cygwin.com/lists.html";>appropriate mailing list . This includes observations about web pages, setup questions, questions about where to find things, questions about why things are done a certain way, questions about the color preferences of Cygwin developers, questions about the meaning of the number 42, etc. Please send notification of technical problems (bad html, broken links) concerning these web pages to http://cygwin.com/lists.html#cygwin";>the cygwin mailing list. Please do not send personal email with "quick questions" to individual cygwin developers. The cygwin mailing lists are the places for all questions. Really. I mean it. Not responsible for errors in content, meaning, tact, or judgement. Live and let live. Toes go in first. Enjoy. Copyright © 2000, 2001,2002 Red Hat, Inc. DO NOT SEND EMAIL TO THIS ADDRESS mailto:[EMAIL PROTECTED]"; color= "white">[EMAIL PROTECTED] IT IS HERE ONLY TO COLLECT SPAM. IF YOU SEND EMAIL TO THIS ADDRESS YOU WILL BE AUTOMATICALLY BLOCKED. --8<--- Soren A -- 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: How to install packages...
Robert Collins <[EMAIL PROTECTED]> wrote in 1032604599.10933.113.camel@lifelesswks:">news:1032604599.10933.113.camel@lifelesswks: > Soren, you should submit the changes as a diff for starters. > Secondly, if at all possible, submit a change against the website CVS. Ah. Second things first: I didn't know there was a website cvs. First things second, my working methods for HTML usually involve running the document through HTML Tidy (W3C.org, also it is now a Cygwin package, FYI). What resulted from doing so in this case was a file in which indentation was introduced (whitespace changed in nearly every line). A diff would have been pointless in that the diff would have been far larger than the entire file. I have doubts about the efficacy and common-sense of rigidly requiring a protocol of 'diffs' against static HTML documents, which are not source code and don't get "compiled" in any sense. In this case I think it made far more sense to submit the entire file which can be simply viewed in a browser (a line reading http://cygwin.com";> could be introduced into the HEAD of the document in order to facilitate preview before going "live" so that relative urls can be resolved, allowing links and inline images to work right, and can be removed if desired once the file is approved). OTOH I grant you that a small number of changes to a large *collection* of static HTML documents *could* be a case where submission of diffs would be the preferable protocol as it would better facilitate oversight of the changes (making sure that the submittor didn't "accidentally" change every instance of "microsoft.com" in URLs to "microslut.com" or anything scandalous like that ;-). Regards, 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: How to install packages...
Robert Collins <[EMAIL PROTECTED]> wrote in 1032604599.10933.113.camel@lifelesswks:">news:1032604599.10933.113.camel@lifelesswks: > Secondly, if at all possible, submit a change against the website CVS. A second follow-up. Robert (and anyone), the "if at all possible" definitely looks not-good. I cannot figure out where in the redhat cvs repos is the Cygwin website. I see a module Listing with modules like "naked-gas" () or "winsup" but nothing that looks like it would be htdocs. Also, even if I *find* it, does the way cvs works mean I'd have to checkout the entire cygwin site module to my hd? I have very limited disk space available at the present time. Any cvs co much over 50MB would overflow my available space or render my system unusable. There's no such thing in cvs as getting only "part of" a module, is there? And also is there any cvs command for simply listing which modules are available on a server (I am using the Web interface to browse the modules right now) or what files are in a certain specific module? I tried a few days ago to figure this (these two questions) out for another project (accessing the cvs sources for Allegro) and could not. Regards, Soren A -- 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/
Trouble w/ autoheader -> autom4te error
Hello, Using autom4te (GNU Autoconf) 2.53a autoheader (GNU Autoconf) 2.53a on CYGWIN_NT-4.0 1.3.10(0.51/3/2) 2002-02-25 11:14 i486 unknown $ /usr/autotool/devel/bin/autoheader /usr/autotool/devel/bin/autom4te: unrecognized option `--trace=' Try `/usr/autotool/devel/bin/autom4te --help' for more information. autoheader: autom4te failed with exit status: 1 at /usr/autotool/devel/bin/autoheader line 163 Any ideas about what's wrong here? Soren A -- 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: Trouble w/ autoheader -> autom4te error
Nicholas Wourms <[EMAIL PROTECTED]> wrote in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: >> autoheader: autom4te failed with exit status: 1 >> at /usr/autotool/devel/bin/autoheader line 163 >> >> Any ideas about what's wrong here? >> > > I already reported this prior to Chuck's extended vacation. He > thinks it might be a bug in Autom4te and said he'd look into it once > he returns (prolly looking like the end of October now). Thanks, Nicholas! Yeah, I know about Chuck's vacation. WRT Autotools, my understanding is that Corinna is splitting maintainership for the whole of it with him, with Chuck authoring the wrapper scripts and she officially looking after the tools like autoconf itself. If that hasn't been superceded by a different arrangement. Maybe Corinna will have a chance to look into this? I was told over at the autoconf List that I should be using 2.54 because 2.53 'is an early alpha release'. I wonder if there are users on List here who might have been using a Autoconf-2.54 they've built themselves from GNU mainline source? The package who's build configuration I am mucking about with is GNU make-3.80rc2, btw. Best, Soren A -- 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/
