RE: problems with XFree
On Thu, 2002-07-25 at 11:20, Harold Hunt wrote: Jehan, Excellent summarization of the thread regarding how we can add /usr/X11R6/bin to the path. Looks like we had Dave Cook and Robert Collins discussing the best way to do things but then the thread died. I don't really think that I know how to implement the best solution here, so I will just have to leave this up to others. I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob
/etc/profile package maintainer (Was: problems with XFree)
On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. It will be a few days before I can assemble the package, though. Thanks, David
Re: /etc/profile package maintainer (Was: problems with XFree)
On Thu, 2002-07-25 at 20:14, David Starks-Browning wrote: On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. Thanks for the offer David... John Marshall has already volunteered off-list though (after a few questions to ascertain the work it entails.) I don't care who maintains it - I'm going to work on the basis of it being John until I'm told otherwise :}. Rob
RE: /etc/profile package maintainer (Was: problems with XFree)
From: Robert Collins [mailto:[EMAIL PROTECTED]] On Thu, 2002-07-25 at 20:14, David Starks-Browning wrote: On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. Sorry David, I should have ack'd this publically. Thanks for the offer David... John Marshall has already volunteered I think you mean me ;) J. off-list though (after a few questions to ascertain the work it entails.) I don't care who maintains it - I'm going to work on the basis of it being John until I'm told otherwise :}. Rob === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: /etc/profile package maintainer (Was: problems with XFree)
On Thu, 2002-07-25 at 20:40, Morrison, John wrote: From: Robert Collins [mailto:[EMAIL PROTECTED]] On Thu, 2002-07-25 at 20:14, David Starks-Browning wrote: On 25 Jul 02, in cygwin-xfree, Robert Collins writes: I've been trying for *ages* to get /etc/profile to be an external file. All' it needs is *someone* willing to be a package maintainer for it. Hardly an onerous role, yet no one seems willing to do it. As soon as someone emails me with their willingness, I can provide the relevant tarall immediately, and that person then can just add /usr/X11R6/bin to the path in /etc/profile. Rob, I'm willing to do this. Sorry David, I should have ack'd this publically. Thanks for the offer David... John Marshall has already volunteered I think you mean me ;) John M, well I got most of it right :}. Yes, I did mean you. Sorry - I will drink more coffee now :}. Rob
Re: problems with XFree
Jehan, As a rule of thumb, packages should *never* modify the /etc/profile script (even if you do back it up). This is a big no-no, as most *nix people would tell you. If you insist on getting into a discussion on why this is, then so be it. Instead, create 2 scripts (a csh and a sh) and drop them into the /etc/profile.d/ directory. This way we play it safe and every one is happy. Also, your scripts should check to see if the path has already been set, if it has, then don't set it again. Remeber, the more entries in the path, the slower Cygwin will operate. Cheers, Nicholas --- Jehan [EMAIL PROTECTED] wrote: Harold Hunt wrote: Jehan, Excellent summarization of the thread regarding how we can add /usr/X11R6/bin to the path. Looks like we had Dave Cook and Robert Collins discussing the best way to do things but then the thread died. I don't really think that I know how to implement the best solution here, so I will just have to leave this up to others. Here is an attempt to add the path into /etc/profile using a post-install script. I first try to see if /etc/profile already sets the X path for people who have customized it. So I grep for something of the form PATH=/usr/X11R6/bin If I find such a line then I do nothing. If the line isn't here, I create a new /etc/profile with the lines: if ! echo $PATH | /bin/grep -q /usr/X11R6/bin ; then PATH=$PATH:/usr/X11R6/bin fi at the top of the file, as suggested in the old thread. Just to be safe, the old profile is renamed /etc/profile.old. Jehan #!/bin/bash TMP_PROFILE=/etc/profile.new if ! /bin/grep -q PATH=.*/usr/X11R6/bin /etc/profile; then cat $TMP_PROFILE EOF if ! echo \$PATH | /bin/grep -q /usr/X11R6/bin ; then PATH=\$PATH:/usr/X11R6/bin fi EOF cat /etc/profile $TMP_PROFILE /bin/mv /etc/profile /etc/profile.old /bin/mv $TMP_PROFILE /etc/profile fi __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
[ITP]: Qt-2.3.1
Harold et al., After a brief discussion this morning, Ralf has given me permission to package QT-2.3.1 and release it to the Cygwin community. I would like to have it under the XFree86 dir, since it is a fully native X library. This release has been throughly tested by us over on the KDE-Cygwin project, pretty much all the bugs have been stomped out. Note that QT does *not* require MIT-SHM [that is kde itself]. Furthermore, I fully intend and expect questions regarding Qt be redirected to the kde-cygwin mailinglist. We should probably update the mailing-lists page's policies to reflect this. My intention is not to inundate this list with Qt/Kde related issues. With the your's and the list's permission, I will package it up and provide the links ASAP. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: [ITP]: Qt-2.3.1
On Thu, Jul 25, 2002 at 05:05:52AM -0700, Nicholas Wourms wrote: Harold et al., After a brief discussion this morning, Ralf has given me permission to package QT-2.3.1 and release it to the Cygwin community. I would like to have it under the XFree86 dir, since it is a fully native X library. This release has been throughly tested by us over on the KDE-Cygwin project, pretty much all the bugs have been stomped out. Note that QT does *not* require MIT-SHM [that is kde itself]. Furthermore, I fully intend and expect questions regarding Qt be redirected to the kde-cygwin mailinglist. We should probably update the mailing-lists page's policies to reflect this. My intention is not to inundate this list with Qt/Kde related issues. With the your's and the list's permission, I will package it up and provide the links ASAP. Are you sure that we don't get licensing issues here? AFAIK, Qt is (roughly) only free when running on a free OS. Basically we're still running on Windows... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ITP]: Qt-2.3.1
On Thu, 2002-07-25 at 22:45, Corinna Vinschen wrote: Are you sure that we don't get licensing issues here? AFAIK, Qt is (roughly) only free when running on a free OS. Basically we're still running on Windows... http://www.trolltech.com/developer/licensing/ Summary, 2.2 and later is QPL and GPL. They may not like it, or they may like it. Who knows. But... they can't stop it. Rob
RE: [ITP]: Qt-2.3.1
Well, remember also that the X11 version is licensed under the GPL, so it is fine. They do make some other versions that are not yet licensed under the GPL. The native Windows version used to be non-GPL, but I think I remember seeing something in the news about this changing a few months ago or something. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Thursday, July 25, 2002 8:52 AM To: [EMAIL PROTECTED] Subject: Re: [ITP]: Qt-2.3.1 On Thu, 2002-07-25 at 22:45, Corinna Vinschen wrote: Are you sure that we don't get licensing issues here? AFAIK, Qt is (roughly) only free when running on a free OS. Basically we're still running on Windows... http://www.trolltech.com/developer/licensing/ Summary, 2.2 and later is QPL and GPL. They may not like it, or they may like it. Who knows. But... they can't stop it. Rob
RE: [ITP]: Qt-2.3.1
--- Harold Hunt [EMAIL PROTECTED] wrote:
Well, remember also that the X11 version is licensed under the GPL,
so it is
fine. They do make some other versions that are not yet licensed
under the
GPL. The native Windows version used to be non-GPL, but I think I
remember
seeing something in the news about this changing a few months ago
or
something.
Harold,
So is this a green light? I'll get started ASAP if it is. I was
thinking that the best bet would be to do like lesstif and put the
qt-2.3.1 tree under:
/usr/X11R6/qt-2.3.1/{bin, include, lib, doc}
What do you think?
Cheers,
Nicholas
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Re: Finally on Sylpheed
--- Jim George [EMAIL PROTECTED] wrote: I say finally but of course the fun is just beginning for me:) I now have sylpheed (the X Mail Client) running under cygwin-X and it's very good, there are some items that could be beefed up/improved upon (and I shall offer whatever help I'm able to) but on the whole very good. So that this isn't one of those mails that just takes up bandwidth... To create it you need glib-1.2.10 and gtk.1.2.10 or above, also libiconv (this is already part of the main setup for cygwin, although you need to specifically select it), and of course you need sylpheed (current release is 0.8.0). You can get glib and gtk at ftp://ftp.gtk.org/pub/gtk/1.2 You can get sylpheed at http://sylpheed.good-day.net You need to make one alteration in the glib package for it to compile. Comment out line 705 of gstrfuncs.c and it will compile flawlessly. Can the lis let me know if there is interest in a X Mail Client for cygwin, in which case I'll investigate becoming a maintainter for the list? Jim, Why don't you wait until Lapo releases the glib/gtk packages. That way you can link to them dynamically. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Finally on Sylpheed
At 23:16 2002-07-24, Jim George wrote: I say finally but of course the fun is just beginning for me:) I now have sylpheed (the X Mail Client) running under cygwin-X ... Can the lis let me know if there is interest in a X Mail Client for cygwin, in which case I'll investigate becoming a maintainter for the list? Cheers, Jim Jim, I'm very interested in a cross-platform replacement for Eudora (for two big reasons: first, I want to get free of Windows but need a transition from my current development environment, which is Windows 2000, and second I want a mailer with message threading, which the Sylpheed FAQ claims is an available option). So yes, I'm very interested in a XFree86/Cygwin port of Sylpheed. Randall Schulz Mountain View, CA USA
Re: problems with XFree
Nicholas Wourms wrote: As a rule of thumb, packages should *never* modify the /etc/profile script (even if you do back it up). This is a big no-no, as most *nix people would tell you. If you insist on getting into a discussion on why this is, then so be it. Instead, create 2 scripts (a csh and a sh) and drop them into the /etc/profile.d/ directory. I don't like modifying /etc/profile either because I don't think there any clean way to do it. But if you read the thread I summarized, someone said that Unixes set X path in /etc/profile. And this make sense to me: there are no guarantees on the order of execution of the scripts in /etc/profile.d. What if one of them looks for X and doesn't find it because the path has not yet been set? As you said in our heated thread last time, X is quite an important package and we will have more and more package depending on it. If the 2 scripts in profile.d are preferred, then I already sent them less than two weeks ago. This way we play it safe and every one is happy. Also, your scripts should check to see if the path has already been set, if it has, then don't set it again. Remeber, the more entries in the path, the slower Cygwin will operate. If you read the scripts carefully, you'll see that I do check if the path exists. I check in the install script if /etc/profile has a line of the form ...PATH=.../usr/X11R6/bin Sure it doesn't handle every single cases (what if someone uses a temporary variable). But it should handle 99.99% of the cases. If such a line is already in /etc/profile, I don't change it. I also check the path in /etc/profile script itself using the echo/grep line. Jehan
Re: [ITP]: Qt-2.3.1
Ralf,
Since KDE on Cygwin might eventually depend on this Qt package, why
don't you guys decide together what the best location would be?
I really have no idea where to put it, so I'm all for just putting it
somewhere and cleaning up the mess later when we learn what we did wrong.
The LSB doesn't specify a location for Qt, does it?
Harold
Ralf Habacker wrote:
--- Harold Hunt [EMAIL PROTECTED] wrote:
Well, remember also that the X11 version is licensed under the GPL,
so it is
fine. They do make some other versions that are not yet licensed
under the
GPL. The native Windows version used to be non-GPL, but I think I
remember
seeing something in the news about this changing a few months ago
or
something.
Harold,
So is this a green light? I'll get started ASAP if it is. I was
thinking that the best bet would be to do like lesstif and put the
qt-2.3.1 tree under:
/usr/X11R6/qt-2.3.1/{bin, include, lib, doc}
under suse linux Qt is installed normally under /usr/lib/qt-release with
symbolic link to /usr/lib/qtmajor_release or into /usr/lib (see below)
habacker@lxserver05:~ rpm -q qt3 -l
/etc/X11/qtrc
/usr/bin/qtconfig
/usr/lib/libqt-mt.so.3
/usr/lib/qt-3.0.4
/usr/lib/qt-3.0.4/bin
/usr/lib/qt-3.0.4/bin/qtconfig
/usr/lib/qt-3.0.4/etc
/usr/lib/qt-3.0.4/etc/settings
/usr/lib/qt-3.0.4/etc/settings/qtrc
/usr/lib/qt-3.0.4/lib
/usr/lib/qt-3.0.4/lib/libqt-mt.so.3
/usr/lib/qt-3.0.4/lib/libqt-mt.so.3.0
/usr/lib/qt-3.0.4/lib/libqt-mt.so.3.0.4
/usr/lib/qt-3.0.4/plugins
/usr/lib/qt-3.0.4/plugins/imageformats
/usr/lib/qt-3.0.4/plugins/imageformats/libqjpeg.so
/usr/lib/qt-3.0.4/plugins/imageformats/libqmng.so
/usr/lib/qt3
habacker@lxserver05:~ rpm -q qt-2.3.1 -l
/etc/qt.fontguess
/usr/lib/libqt-mt.so.2
/usr/lib/libqt.so.2
/usr/lib/libqutil.so.1
/usr/lib/qt-2.3.1
/usr/lib/qt-2.3.1/lib
/usr/lib/qt-2.3.1/lib/libqt-mt.so
/usr/lib/qt-2.3.1/lib/libqt-mt.so.2
/usr/lib/qt-2.3.1/lib/libqt-mt.so.2.3
/usr/lib/qt-2.3.1/lib/libqt-mt.so.2.3.1
/usr/lib/qt-2.3.1/lib/libqt.so
/usr/lib/qt-2.3.1/lib/libqt.so.2
/usr/lib/qt-2.3.1/lib/libqt.so.2.3
/usr/lib/qt-2.3.1/lib/libqt.so.2.3.1
/usr/lib/qt-2.3.1/lib/libqutil.so
/usr/lib/qt-2.3.1/lib/libqutil.so.1
/usr/lib/qt-2.3.1/lib/libqutil.so.1.0
/usr/lib/qt-2.3.1/lib/libqutil.so.1.0.0
/usr/lib/qt2
/usr/share/doc/packages/qt/doc
/usr/share/doc/packages/qt/doc/ANNOUNCE
/usr/share/doc/packages/qt/doc/FAQ
/usr/share/doc/packages/qt/doc/INSTALL
/usr/share/doc/packages/qt/doc/LICENSE.GPL
/usr/share/doc/packages/qt/doc/LICENSE.QPL
/usr/share/doc/packages/qt/doc/MANIFEST
/usr/share/doc/packages/qt/doc/PLATFORMS
/usr/share/doc/packages/qt/doc/PORTING
/usr/share/doc/packages/qt/doc/README
/usr/share/doc/packages/qt/doc/README.QT
/usr/share/doc/packages/qt/doc/README.SuSE
/usr/share/doc/packages/qt/doc/changes-2.3.0
/usr/share/doc/packages/qt/doc/changes-2.3.1
Ralf
Re: [ITP]: Qt-2.3.1
--- Harold L Hunt II [EMAIL PROTECTED] wrote: Ralf, Since KDE on Cygwin might eventually depend on this Qt package, why don't you guys decide together what the best location would be? I really have no idea where to put it, so I'm all for just putting it somewhere and cleaning up the mess later when we learn what we did wrong. The LSB doesn't specify a location for Qt, does it? I thought the decision was that all X stuff should go under X11R6/, but I could have misinterpreted the thread. If not there, based on the LSB, I'd be inclined to stick in /opt, but if Ralf really wants to put it under /usr/lib then I'll do that. Ralf? Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
RE: Obtaining Hummingbird-like behavior
Harold, I'd like to contribute. My handicaps would be Time. I'm moving from Texas to San Diego in a few weeks. Same company, better job. You know what that involves. Skill. I'm but a humble system admin - my coding skills (basic PERL, shell scripting aside) are weak to non-existent*. So .. yah, I'm for it, to scratch an itch and reap fame and glory. Give me a nudge to set me on the path? ~Brian * I actually 'learned' COBOL and dBaseIII/Clipper '87 a long, long time ago, when I was young and foolish, but I'm not sure how much of that training would apply. -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 24, 2002 10:30 PM To: [EMAIL PROTECTED] Subject: RE: Obtaining Hummingbird-like behavior Brian, Assuming you're not speaking tongue in cheek, Nicholas, I can see a need for doing this ... and intend to demo it on some of haplass end users someday. Does this mean that you are working on a rootless mode for Cygwin/XFree86? Harold
Re: Case Closed (was Re: Help with fixing x2x...)
Thomas,
Excellent.
In xwinclip I calculate the maximum socket number just like you are doing:
/* Find max of our file descriptors */
iMaxDescriptor = max (fdMessageQueue, iConnectionNumber) + 1;
At least it is fixed now.
Harold
Thomas Chadwick wrote:
Well, I figured it out. The buggy behavior was indeed due to a bogus
value of nfds. After poking around in the xfree86 source, I came across
xc/lib/Xt/Display.c, which manipulates its own nfds variable in much the
same way as x2x.
In short, changing this:
/* set up for select */
nfds = getdtablesize();
fdset = (fd_set *)malloc(sizeof(fd_set));
fromConn = XConnectionNumber(fromDpy);
toConn = XConnectionNumber(toDpy);
To this:
/* set up for select */
fdset = (fd_set *)malloc(sizeof(fd_set));
fromConn = XConnectionNumber(fromDpy);
toConn = XConnectionNumber(toDpy);
nfds = MAX(fromConn, toConn) + 1;
Does the trick. However, before I repackage it for Cygwin Setup, I'll
probably apply many (if not all) of Harold's suggestions as well.
Thanks, everyone!
From: Harold L Hunt II [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Help with fixing x2x...
Date: Wed, 24 Jul 2002 15:17:52 -0400
Thomas Chadwick wrote:
Hmmm. I tried your suggestion and the behavior has not changed. It's
still gobbling up 99% of the CPU. Suspecting that select() is not
blocking like it should, I inserted printf(Hello\n); just before the
select() function call. Now when I run x2x I get a continuous stream of
Hellos on STDOUT whether or not I'm moving the mouse or typing.
By comparison, I compiled x2x on my AIX workstation, including the
Hello addition. When I run x2x there, I observe that it only prints
Hello when I move the mouse or hit a key. This seems to me to be the
appropriate behavior.
This little experiment implicates the select() function call itself as
being the source of the trouble. Now the question is, is it a problem
with how select() is being used (and if so, is the problem at the
Xserver or the Xclient end), or is there a problem with the Cygwin
implementation of it?
Are you aware of any Xclients which use select() and yet do not exhibit
the non-blocking behavior I'm seeing? Perhaps there is a minor tweak
required in how it is being called.
Yup, xwinclip uses select () just like x2x does:
http://xfree86.cygwin.com/devel/xwinclip/changelog.html
Just download the tarball for Test06 and look in xwinclip.c/main ()/Line
390.
I think the problem may be with the value that getdtablesize () is
returning. To find out, you need to printf the value of nfds, fromConn,
and toConn. If nfds isn't at least one larger than the maximum of
fromConn and toConn, then you have a problem. You can alternatively
replace nfds in the call to select with FD_SETSIZE.
Probably the main problem here, other than if nfds is incorrect, is that
the event loop fails to flush all X events before its first call to
select (), which is necessary because there may be events stored in
local structures already. Also, the manner in which the program
determines whether or not events are pending is non-standard and easy to
break.
One other thing: the original programmer is malloc'ing fdset and freeing
it later. This is entirely unnecessary, fdset should be an automatic
variable instead.
I recommend completely replaceing the DoX2X function with the one below.
I promise that it will work this time :)
Harold
static void DoX2X(fromDpy, toDpy)
Display *fromDpy;
Display *toDpy;
{
DPYINFO dpyInfo;
fd_setfdset;
int fromConn, toConn;
int iReturn;
Bool fReturn;
/* set up displays */
dpyInfo.fromDpy = fromDpy;
dpyInfo.toDpy = toDpy;
InitDpyInfo (dpyInfo);
RegisterEventHandlers (dpyInfo);
/* get file handles for display event pipes */
fromConn = XConnectionNumber(fromDpy);
toConn = XConnectionNumber(toDpy);
/*
* We have to clear any pending events before our
* first call to select, because there may be events
* stored in local structures. Failing to clear these
* events will lead to select failing to operate
* properly. We just set the event flags here so
* that both event loops are entered on the first time
* through the main loop below.
*/
FD_ZERO (fdset);
FD_SET (fromConn, fdset);
FD_SET (toConn, fdSet);
/* Loop forever */
while (True)
{
/* Check for events for From display */
if (FD_ISSET (fromConn, fdset))
{
/* Process any pending events for From display */
while (XPending (fromDpy))
fReturn = ProcessEvent (fromDpy, dpyInfo);
/* Check for failure */
if (fReturn) break;
}
/* Check for events for To display */
if (FD_ISSET (toConn, fdset))
{
/* Process any pending events for To display */
while (XPending (toDpy))
Re: problems with XFree
Let me see if I understand what is going on here: We are debeating whether to: 1) Modify /etc/profile, which is not installed via a package, but is created directly by setup.exe. 2) Add two scripts, one for bash-style shells and one for c-shell-style shells to /etc/profile.d/. These scripts are processed by /etc/profile. We would add this new scripts to an XFree86 package, probably XFree86-bin, and we would install these scripts via a post-install script if they were not already present (so we do not overwrite modifications). Of all the arguments for/against the two methods, so far only one seems to be a sticking point that essentially decides how we will do this: There is no guarantee that the sub-script in /etc/profile.d/ that adds /usr/X11R6/bin to the path will be executed before some other shell script, that may be added at a later date to /etc/profile.d/, that requires that the path to the X11R6 binaries already be set. In order to allow other scripts in /etc/profile.d/ to assume that the path to the X11R6 binaries is known, we must set the path to the binaries in /etc/profile before the /etc/profile.d/ scripts are processed. I therefore throw my vote 100% behind modifying the /etc/profile script to add /usr/X11R6/bin to the path, if that directory exists. Robert Collins had said something about pulling the /etc/profile script out of setup.exe and having it installed as a stand-alone package. Was this the task that two people had volunteered for? If so, shall we wait until this package is made before we propose any changes to /etc/profile, or should we go ahead and submit a patch for the /etc/profile that is distributed with setup.exe now? Hopefully I haven't confused anything here. I have not commented until now because I had no idea what was going on with all of this profile[.d] stuff, but I think I have a pretty good grasp of it now. Harold Jehan wrote: Nicholas Wourms wrote: As a rule of thumb, packages should *never* modify the /etc/profile script (even if you do back it up). This is a big no-no, as most *nix people would tell you. If you insist on getting into a discussion on why this is, then so be it. Instead, create 2 scripts (a csh and a sh) and drop them into the /etc/profile.d/ directory. I don't like modifying /etc/profile either because I don't think there any clean way to do it. But if you read the thread I summarized, someone said that Unixes set X path in /etc/profile. And this make sense to me: there are no guarantees on the order of execution of the scripts in /etc/profile.d. What if one of them looks for X and doesn't find it because the path has not yet been set? As you said in our heated thread last time, X is quite an important package and we will have more and more package depending on it. If the 2 scripts in profile.d are preferred, then I already sent them less than two weeks ago. This way we play it safe and every one is happy. Also, your scripts should check to see if the path has already been set, if it has, then don't set it again. Remeber, the more entries in the path, the slower Cygwin will operate. If you read the scripts carefully, you'll see that I do check if the path exists. I check in the install script if /etc/profile has a line of the form ...PATH=.../usr/X11R6/bin Sure it doesn't handle every single cases (what if someone uses a temporary variable). But it should handle 99.99% of the cases. If such a line is already in /etc/profile, I don't change it. I also check the path in /etc/profile script itself using the echo/grep line. Jehan
Re: problems with xfree
Christopher Faylor wrote: On Thu, Jul 25, 2002 at 04:47:39PM -0400, Harold L Hunt II wrote: Let me see if I understand what is going on here: We are debeating whether to: 1) Modify /etc/profile, which is not installed via a package, but is created directly by setup.exe. 2) Add two scripts, one for bash-style shells and one for c-shell-style shells to /etc/profile.d/. These scripts are processed by /etc/profile. We would add this new scripts to an XFree86 package, probably XFree86-bin, and we would install these scripts via a post-install script if they were not already present (so we do not overwrite modifications). Of all the arguments for/against the two methods, so far only one seems to be a sticking point that essentially decides how we will do this: There is no guarantee that the sub-script in /etc/profile.d/ that adds /usr/X11R6/bin to the path will be executed before some other shell script, that may be added at a later date to /etc/profile.d/, that requires that the path to the X11R6 binaries already be set. In order to allow other scripts in /etc/profile.d/ to assume that the path to the X11R6 binaries is known, we must set the path to the binaries in /etc/profile before the /etc/profile.d/ scripts are processed. I don't know what this other script in /etc/profile.d might be, but if it is a problem for the other script, it could easily include /etc/profile.d/add_x11_path (or whatever) to add the script to ensure that the path was properly set. So, I think that adding an appropriate file to /etc/profile.d makes more sense. Then people who don't have /usr/bin/X11R6 don't have a spurious check for the directory in their /etc/profile. cgf That sounds even more reasonable. No one has suggested that yet. One question though... are there any known packages that put a script in /etc/profile.d/ that expect the path to the X11R6 binaries to already be set, but that do not include some X11R6 path-setting script? We would have to modify any such scripts, if we ever encounter them, to include our X11R6 path-setting script. That doesn't seem like a horrible trade-off. Okay, go with the new scripts in /etc/profile.d/. Jehan - you sent in these scripts before, right? Could you send them again? Thanks. Harold
/etc/profile /etc/profile.d/ (was: problems with XFree)
As I understand it, the whole point of /etc/profile.d/ is to allow packages to put their own startup scripts there and not modify /etc/profile - the underlying reason being that package management generally does a good job of adding and removing files, but changing them is fraught with difficulty. 2) Add two scripts, one for bash-style shells and one for c-shell- style shells to /etc/profile.d/. These scripts are processed by /etc/profile. We would add this new scripts to an XFree86 package, probably XFree86-bin, and we would install these scripts via a post-install script if they were not already present (so we do not overwrite modifications). Why not just install them normally? Is this not the whole point of profile.d ? Of all the arguments for/against the two methods, so far only one seems to be a sticking point that essentially decides how we will do this: There is no guarantee that the sub-script in /etc/profile.d/ that adds /usr/X11R6/bin to the path will be executed before some other shell script, that may be added at a later date to /etc/profile.d/, that requires that the path to the X11R6 binaries already be set. In order to allow other scripts in /etc/profile.d/ to assume that the path to the X11R6 binaries is known, we must set the path to the binaries in /etc/profile before the /etc/profile.d/ scripts are processed. Can I just raise a point? If we named the script 00-XFree-path.sh, then wouldn't the 00 prefix ensure that this script executed before any scripts with first-character-alphabetic names? This seems to me the best way to solve this problem, unless someone can show that this ordering is not necessarily so. I therefore throw my vote 100% behind modifying the /etc/profile script to add /usr/X11R6/bin to the path, if that directory exists. I really don't think we should be messing with /etc/profile for this kind of thing. This is the raison d'être of /etc/profile.d/ . Robert Collins had said something about pulling the /etc/profile script out of setup.exe and having it installed as a stand-alone package. Was this the task that two people had volunteered for? If so, shall we wait until this package is made before we propose any changes to /etc/profile, or should we go ahead and submit a patch for the /etc/profile that is distributed with setup.exe now? Not _with_. _In_. Hopefully I haven't confused anything here. I have not commented until now because I had no idea what was going on with all of this profile[.d] stuff, but I think I have a pretty good grasp of it now. Actually, that was a pretty useful synopsis of the current situation. Harold Max.
Re: Finally on Sylpheed
Hi Jim, I use cygwin-sylpheed for almost an year. It has become my main email client. Of course I am interested that anybody becomes the maintainter of this great program. Furthermore I am interested in an official cygwin glib/gtk port. -Jack
