date:20031208

Hi,

There are a bunch of applications, which, for security reasons, want to
set $PATH to a fixed value.  This approach is a bit tricky on Windows,
since the needed paths to the Windows system directories are not fixed
values as it's on POSIX systems.  A lot of applications are falling back
to values like _PATH_DEFPATH or _PATH_STDPATH and use them to set $PATH
before starting another application.  Sshd, login, cron are just three
of them.  The current patches to all three applications are so that the
code which sets $PATH before exec'ing another process is not executed
when built for Cygwin.

I think a better approach is this:  Let's generalize the idea of a fixed
path to the Windows system directories.  I suggest, that one of the base
install scripts creates a symlink "/WINDOWS" like this:

  ln -s `cygpath -m "$WINDIR"` /WINDOWS

This allows to keep the above described code to set $PATH in the
affected tools, just by redefining, say _PATH_DEFPATH like this:

#ifdef _PATH_DEFPATH
#undef _PATH_DEFPATH
#define _PATH_DEFPATH 
"/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
#endif

which contains both, NT and 9x paths.  We could perhaps even change
/usr/include/paths.h to reflect this, at one point.


Opinions?

Corinna
-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: [ITP] ddd-3.3.8

2003-12-08 Thread Ronald Landheer-Cieslak

This definitely has my vote - anything that makes debugging easier is a 
Good Thing IMHO.

rlc

On Fri, Dec 05, 2003 at 09:38:15PM -0500, Harold L Hunt II wrote:
> I would like to contribute and maintain ddd:
> 
> http://www.gnu.org/software/ddd/
> 
> GNU DDD is a graphical front-end for command-line debuggers such as
> GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, or the Python
> debugger. Besides ``usual'' front-end features such as viewing source
> texts, DDD has become famous through its interactive graphical data
> display, where data structures are displayed as graphs.
> 
> 
> You can point Cygwin's setup.exe to the following address to install and 
> test ddd:
> 
> http://www.egr.msu.edu/~huntharo/cygwin/
> 
> ***Reviewer's Caveat***: I don't think that the static libiberty.a is 
> supposed to be installed, so I removed the /usr/lib directory in the 
> install step of the build script.
> 
>  cut here --
> 
> #!/bin/bash
> 
> mkdir ddd
> cd ddd
> 
> wget \
> http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/setup.hint
> 
> wget \
> http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1.tar.bz2
> 
> wget \
> http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1-src.tar.bz2
> 
>  cut here --
> 
> MD5 sums:
> 
> de2d743b95817745c4227427afec759b *ddd/ddd-3.3.8-1-src.tar.bz2
> 86cc2b9dff9a4f794dfc6bbe49bf2bbc *ddd/ddd-3.3.8-1.tar.bz2
> 2c6bec0f95a7c76ee6581133eeab1db6 *ddd/setup.hint
> 
> 
> Harold

-- 
It's later than you think.

Re: /WINDOWS

2003-12-08 Thread Ronald Landheer-Cieslak

Good idea, except that I'd personally prefer a mount point in stead of a 
symlink but that's just personal preference.. (Personally, I'd prefer that
the Cygwin DLL make /WINDOWS a "magical" mountpoint to the likeness of 
/dev, /proc, etc. so as to make it completely transparent and make sure no
user can "accidentally" remove the symlink, so as to make sure that the
programs can actually rely on it being there and on it to behave as a "normal"
directory..)

rlc


On Mon, Dec 08, 2003 at 11:29:27AM +0100, Corinna Vinschen wrote:
> There are a bunch of applications, which, for security reasons, want to
> set $PATH to a fixed value.  This approach is a bit tricky on Windows,
> since the needed paths to the Windows system directories are not fixed
> values as it's on POSIX systems.  A lot of applications are falling back
> to values like _PATH_DEFPATH or _PATH_STDPATH and use them to set $PATH
> before starting another application.  Sshd, login, cron are just three
> of them.  The current patches to all three applications are so that the
> code which sets $PATH before exec'ing another process is not executed
> when built for Cygwin.
> 
> I think a better approach is this:  Let's generalize the idea of a fixed
> path to the Windows system directories.  I suggest, that one of the base
> install scripts creates a symlink "/WINDOWS" like this:
> 
>   ln -s `cygpath -m "$WINDIR"` /WINDOWS
> 
> This allows to keep the above described code to set $PATH in the
> affected tools, just by redefining, say _PATH_DEFPATH like this:
> 
> #ifdef _PATH_DEFPATH
> #undef _PATH_DEFPATH
> #define _PATH_DEFPATH 
> "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
> #endif
> 
> which contains both, NT and 9x paths.  We could perhaps even change
> /usr/include/paths.h to reflect this, at one point.
> 
> 
> Opinions?
> 
> Corinna
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Developermailto:[EMAIL PROTECTED]
> Red Hat, Inc.

-- 
Double!

[Review] dx-4.3.2 (a.k.a. opendx) and dxsamples-4.3.2

2003-12-08 Thread Dr. Volker Zell

> "Harold" == Harold L Hunt,  writes:

Harold> I would like to contribute and maintain dx and dxsamples for Cygwin:

Harold>  http://www.opendx.org/

I vote pro. Compiles and installs fine on my system. Packaging looks good.

Ciao
  Volker

Re: /WINDOWS

On Dec  8 14:14, Ronald Landheer-Cieslak wrote:
> Good idea, except that I'd personally prefer a mount point in stead of a 
> symlink but that's just personal preference.. (Personally, I'd prefer that
> the Cygwin DLL make /WINDOWS a "magical" mountpoint to the likeness of 
> /dev, /proc, etc. so as to make it completely transparent and make sure no
> user can "accidentally" remove the symlink, so as to make sure that the
> programs can actually rely on it being there and on it to behave as a "normal"
> directory..)

Yes, that's a good idea, too.  And it also would remove a potential
security problem if anybody could redirect the /WINDOWS link to some
tainted directory.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: [Review] dx-4.3.2 (a.k.a. opendx) and dxsamples-4.3.2

Volker,

Thanks for the vote and the review.

I will probably hold off on posting until I replace ImageMagick with 
GraphicsMagick.

Harold

Dr. Volker Zell wrote:
"Harold" == Harold L Hunt,  writes:


Harold> I would like to contribute and maintain dx and dxsamples for Cygwin:

Harold>  http://www.opendx.org/

I vote pro. Compiles and installs fine on my system. Packaging looks good.

Ciao
  Volker

Re: [ITP] ddd-3.3.8

Ronald,

Did you point setup.exe to the address given, install it, and run it? 
If so, that would be enough of a review for me.  I just want to make 
sure it works on someone else's installation.

Harold

Ronald Landheer-Cieslak wrote:

This definitely has my vote - anything that makes debugging easier is a 
Good Thing IMHO.

rlc

On Fri, Dec 05, 2003 at 09:38:15PM -0500, Harold L Hunt II wrote:

I would like to contribute and maintain ddd:

   http://www.gnu.org/software/ddd/

GNU DDD is a graphical front-end for command-line debuggers such as
GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, or the Python
debugger. Besides ``usual'' front-end features such as viewing source
texts, DDD has become famous through its interactive graphical data
display, where data structures are displayed as graphs.
You can point Cygwin's setup.exe to the following address to install and 
test ddd:

http://www.egr.msu.edu/~huntharo/cygwin/

***Reviewer's Caveat***: I don't think that the static libiberty.a is 
supposed to be installed, so I removed the /usr/lib directory in the 
install step of the build script.

 cut here --

#!/bin/bash

mkdir ddd
cd ddd
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1-src.tar.bz2
 cut here --

MD5 sums:

de2d743b95817745c4227427afec759b *ddd/ddd-3.3.8-1-src.tar.bz2
86cc2b9dff9a4f794dfc6bbe49bf2bbc *ddd/ddd-3.3.8-1.tar.bz2
2c6bec0f95a7c76ee6581133eeab1db6 *ddd/setup.hint
Harold

[ITP - Ready for review] GraphicsMagick

[This package will replace ImageMagick for various reasons.  One of
those reasons is that the GM folks are committed to provide ABI
stability and proper version numbers, whereas IM is not making such a
committment and has already made various arbitrary changes to ABI
version numbers.]
I would like to contribute and maintain GraphicsMagick:

http://www.graphicsmagick.org/

Tester's Notes
==
You can point Cygwin's setup.exe to the following address to download
and test the GraphicsMagick package:
http://www.egr.msu.edu/~huntharo/cygwin/

Reviewer's Notes

1) I moved the bin/*-config scripts into the -devel package.
2) I moved the /usr/lib/GraphicsMagick-1.0.4 directory into the main
package... but I think it probably should go in the libGraphicsMagick0
package instead.  Chuck and I have been discussing this a lot but I got
confused about where the final location should be; I also realized that
I don't know what the final location should be, so I want to get some
instruction before I move this directory again.  The deciding issue
would be whether the libraries query /usr/lib/GraphicsMagick-1.0.4 or
whether only gm.exe queries it; if the libraries query it then the
directory must be in the libGraphicsMagick0 package, right?
3) You'll notice that the patch file changes the version.sh script to
report 1.0.4 (it was reporting 1.0.5), while the official source
tarballs don't need this change.  The reason is that I told Bob about
this fix and he changed the 1.0.4 source tarballs instead of bumping the
version number to 1.0.6... I have not grabbed the newest 1.0.4 source
tarball so I still have the patch.
4) My build is done with --enable-shared but without --with-modules
(these are what I used for ImageMagick too).  It seems from the
discussions that the /usr/lib/GraphicsMagick-1.0.4 directory does not
need to be broken out into a separate versioned package and can be left
in either GraphicsMagick or libGraphicsMagick0 (see #2 above).
 cut here --
#!/bin/bash
mkdir GraphicsMagick
cd GraphicsMagick
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/GraphicsMagick-1.0.4-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/GraphicsMagick-1.0.4-1-src.tar.bz2
mkdir libGraphicsMagick0
cd libGraphicsMagick0
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick0/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick0/libGraphicsMagick0-1.0.4-1.tar.bz2
cd ..
mkdir libGraphicsMagick-devel
cd libGraphicsMagick-devel
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick-devel/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick-devel/libGraphicsMagick-devel-1.0.4-1.tar.bz2
 cut here --
MD5 sums:

0fbfb35218b8a577336849030a877e2b *./GraphicsMagick-1.0.4-1-src.tar.bz2
62f1225540aa6fcf293efa6fe6911d8c *./GraphicsMagick-1.0.4-1.tar.bz2
056ca31a2b6aaea00016c23913566c15
*./libGraphicsMagick-devel/libGraphicsMagick-devel-1.0.4-1.tar.bz2
149e44c2a070ea7cea3ea52b43aba37a *./libGraphicsMagick-devel/setup.hint
eb22a32397dc9e3866db221c6c47b984
*./libGraphicsMagick0/libGraphicsMagick0-1.0.4-1.tar.bz2
cc1846262c4ce0277166d6947f71540d *./libGraphicsMagick0/setup.hint
d41d8cd98f00b204e9800998ecf8427e *./md5.sum
3cb9210d7f7f7306d9b95fce981aa7cd *./setup.hint
Harold

Re: [ITP - Ready for review] GraphicsMagick

Sorry, disregard this repost.  I have been having some mailer trouble 
and thought it didn't get through.  I will be posting an updated 
announcement shortly.

Harold

Re: /WINDOWS

On Mon, 8 Dec 2003, Corinna Vinschen wrote:

> Hi,
>
> There are a bunch of applications, which, for security reasons, want to
> set $PATH to a fixed value.  This approach is a bit tricky on Windows,
> since the needed paths to the Windows system directories are not fixed
> values as it's on POSIX systems.  A lot of applications are falling back
> to values like _PATH_DEFPATH or _PATH_STDPATH and use them to set $PATH
> before starting another application.  Sshd, login, cron are just three
> of them.  The current patches to all three applications are so that the
> code which sets $PATH before exec'ing another process is not executed
> when built for Cygwin.
>
> I think a better approach is this:  Let's generalize the idea of a fixed
> path to the Windows system directories.  I suggest, that one of the base
> install scripts creates a symlink "/WINDOWS" like this:
>
>   ln -s `cygpath -m "$WINDIR"` /WINDOWS
>
> This allows to keep the above described code to set $PATH in the
> affected tools, just by redefining, say _PATH_DEFPATH like this:
>
> #ifdef _PATH_DEFPATH
> #undef _PATH_DEFPATH
> #define _PATH_DEFPATH 
> "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
> #endif
>
> which contains both, NT and 9x paths.  We could perhaps even change
> /usr/include/paths.h to reflect this, at one point.
>
> Opinions?
> Corinna

FWIW, I agree that it's a good idea to have a fixed pointer to the windows
directory, but I don't think "/" is the right place to have it.  Could we
make it "/mnt/WINDOWS" or "/opt/WINDOWS" or something?  I don't like
cluttering up the root directory unnecessarily...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

RE: /WINDOWS

2003-12-08 Thread Morrison, John

Igor Pechtchanski wrote:
> On Mon, 8 Dec 2003, Corinna Vinschen wrote:
> 
>> Hi,
>> 
>> There are a bunch of applications, which, for security reasons, want
>> to set $PATH to a fixed value.  This approach is a bit tricky on
>> Windows, since the needed paths to the Windows system directories
>> are not fixed values as it's on POSIX systems.  A lot of
>> applications are falling back to values like _PATH_DEFPATH or
>> _PATH_STDPATH and use them to set $PATH before starting another
>> application.  Sshd, login, cron are just three of them.  The current
>> patches to all three applications are so that the code which sets
>> $PATH before exec'ing another process is not executed when built for
>> Cygwin.  
>> 
>> I think a better approach is this:  Let's generalize the idea of a
>> fixed path to the Windows system directories.  I suggest, that one
>> of the base install scripts creates a symlink "/WINDOWS" like this:
>> 
>>   ln -s `cygpath -m "$WINDIR"` /WINDOWS
>> 
>> This allows to keep the above described code to set $PATH in the
>> affected tools, just by redefining, say _PATH_DEFPATH like this:
>> 
>> #ifdef _PATH_DEFPATH
>> #undef _PATH_DEFPATH
>> #define _PATH_DEFPATH
> "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WIN
> DOWS/system32/Wbem"
>> #endif
>> 
>> which contains both, NT and 9x paths.  We could perhaps even change
>> /usr/include/paths.h to reflect this, at one point.
>> 
>> Opinions?
>> Corinna
> 
> FWIW, I agree that it's a good idea to have a fixed pointer to the
> windows directory, but I don't think "/" is the right place to have
> it.  Could we make it "/mnt/WINDOWS" or "/opt/WINDOWS" or something? 
> I don't like cluttering up the root directory unnecessarily...

I like the /mnt idea :)
I'd also like it to have /cygdrive/[insert drive letter here]/
as /mnt/[insert drive letter here]/ too (possibly instead of?)

J.

PS, I know I can change what /cygdrive is refered to as.

==
Information in this e-mail 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 binding commitment through 
the use of this electronic communication unless it is issued in accordance 
with the Experian Limited standard terms and conditions of purchase or 
other express written agreement between Experian Limited and the recipient 
Experian Limited (registration number 653331) Registered office: 
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this communication 
and any attachments are free from computer virus, you are advised to take 
your own steps to ensure that they are actually virus free.

RE: /WINDOWS

On Mon, 8 Dec 2003, Morrison, John wrote:

> Igor Pechtchanski wrote:
> > On Mon, 8 Dec 2003, Corinna Vinschen wrote:
> >
> >> Hi,
> >>
> >> There are a bunch of applications, which, for security reasons, want
> >> to set $PATH to a fixed value.  This approach is a bit tricky on
> >> Windows, since the needed paths to the Windows system directories
> >> are not fixed values as it's on POSIX systems.  A lot of
> >> applications are falling back to values like _PATH_DEFPATH or
> >> _PATH_STDPATH and use them to set $PATH before starting another
> >> application.  Sshd, login, cron are just three of them.  The current
> >> patches to all three applications are so that the code which sets
> >> $PATH before exec'ing another process is not executed when built for
> >> Cygwin.
> >>
> >> I think a better approach is this:  Let's generalize the idea of a
> >> fixed path to the Windows system directories.  I suggest, that one
> >> of the base install scripts creates a symlink "/WINDOWS" like this:
> >>
> >>   ln -s `cygpath -m "$WINDIR"` /WINDOWS
> >>
> >> This allows to keep the above described code to set $PATH in the
> >> affected tools, just by redefining, say _PATH_DEFPATH like this:
> >>
> >> #ifdef _PATH_DEFPATH
> >> #undef _PATH_DEFPATH
> >> #define _PATH_DEFPATH 
> >> "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
> >> #endif
> >>
> >> which contains both, NT and 9x paths.  We could perhaps even change
> >> /usr/include/paths.h to reflect this, at one point.
> >>
> >> Opinions?
> >> Corinna
> >
> > FWIW, I agree that it's a good idea to have a fixed pointer to the
> > windows directory, but I don't think "/" is the right place to have
> > it.  Could we make it "/mnt/WINDOWS" or "/opt/WINDOWS" or something?
> > I don't like cluttering up the root directory unnecessarily...
>
> I like the /mnt idea :)
> I'd also like it to have /cygdrive/[insert drive letter here]/
> as /mnt/[insert drive letter here]/ too (possibly instead of?)
>
> J.
>
> PS, I know I can change what /cygdrive is refered to as.

That's what I use on my machine:

$ mount
[snip]
c: on /mnt/c type user (binmode)

HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: /WINDOWS

On Dec  8 08:41, Igor Pechtchanski wrote:
> FWIW, I agree that it's a good idea to have a fixed pointer to the windows
> directory, but I don't think "/" is the right place to have it.  Could we
> make it "/mnt/WINDOWS" or "/opt/WINDOWS" or something?  I don't like
> cluttering up the root directory unnecessarily...
>   Igor

I don't agree that we should move the /WINDOWS directory into some
subdir since it's a pretty important path and doesn't have to be
hidden artificially.  In turn I could ask why you want to clutter
the root directory with something like /mnt.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: /WINDOWS

2003-12-08 Thread Bruce Ingalls

This allows to keep the above described code to set $PATH in the

affected tools, just by redefining, say _PATH_DEFPATH like this:

#ifdef _PATH_DEFPATH
#undef _PATH_DEFPATH
#define _PATH_DEFPATH
"/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
#endif
which contains both, NT and 9x paths. We could perhaps even change
/usr/include/paths.h to reflect this, at one point.

This is not correct. the NT paths are (combined with your above paths)

"/usr/bin:/bin:$SYSTEMROOT/system32:$SYSTEMROOT:$SYSTEMROOT/COMMAND:$SYSTEMROOT/system32/Wbem"
(and actually a few more paths, with some variation by w32 version)
$SYSTEMROOT is NOT the same thing as C:\WINDOWS, even if
that is what your system reports.
OK, Cygwin has to escape/expand $SYSTEMROOT, because it is not good
to have ":" in your Linux-like path names. I digress.
However, consider a system, where disk space is running low on the C: drive, so
most data & programs are on the D:, or other drives. Or possibly centralized on a
networked N: drive. This happens often to me, btw.
OK, now I'm going to get crazy with this scenario:
Cygwin is on the D: drive. The SYSTEMROOT is on the E: drive. However the E: drive
gets network remapped (can thin clients do this?) or is ASSIGNed or SUBSTed.
Now the problem is, SYSTEMROOT is set in the registry.
How well is this registry key protected from crackers?
And, in any case, if we do believe that c:\windows or /windows is in our PATH,
how do we know that the directory has not been hijacked through a symlink,
subst, shortcut or assign?
OTOH, a cracker could try to modify your PATH setting script to
"/cracker/bin:/usr/bin:/bin:..."
Although, where ntfs is fully supported, you can limit permissions on the script file.
I hope this helps.

RE: /WINDOWS

2003-12-08 Thread Jörg Schaible

Corinna Vinschen wrote on Monday, December 08, 2003 11:29 AM:
> #ifdef _PATH_DEFPATH
> #undef _PATH_DEFPATH
> #define _PATH_DEFPATH
> "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WIN
> DOWS/system32/Wbem" #endif
> 
> which contains both, NT and 9x paths.  We could perhaps even
> change /usr/include/paths.h to reflect this, at one point.

Just one side note: Are you sure, that the orthography of all these subdirectories is 
the same for all Windows plattforms (at least with VFAT or NTFS)? You might get 
problems with the strict setting otherwise.

Regards,
Jörg

Re: /WINDOWS

On Dec  8 10:17, Bruce Ingalls wrote:
> This allows to keep the above described code to set $PATH in the
> 
> >affected tools, just by redefining, say _PATH_DEFPATH like this:
> >
> >#ifdef _PATH_DEFPATH
> >#undef _PATH_DEFPATH
> >#define _PATH_DEFPATH 
> >"/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
> >#endif
> >
> >which contains both, NT and 9x paths.  We could perhaps even change
> >/usr/include/paths.h to reflect this, at one point.
> >
> > 
> >
> This is not correct. the NT paths are (combined with your above paths)
> 
> "/usr/bin:/bin:$SYSTEMROOT/system32:$SYSTEMROOT:$SYSTEMROOT/COMMAND:$SYSTEMROOT/system32/Wbem"
> (and actually a few more paths, with some variation by w32 version)

Huh?  I was talking about /WINDOWS in a Cygwin sense.  /WINDOWS gets
resolved by either a symlink, a mount point or in Cygwin internally.
/WINDOWS is not C:/WINDOWS but the path given by GetWindowsDirectory().
C:/WINDOWS is just an obvious example.

> OTOH, a cracker could try to modify your PATH setting script to
> "/cracker/bin:/usr/bin:/bin:..."

I'm talking about daemon process which set $PATH to something minimized
and reliable.  That's not a path coming from the outside but a fixed
string compiled into the daemon binary.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: /WINDOWS

On Dec  8 16:34, J?rg Schaible wrote:
> Corinna Vinschen wrote on Monday, December 08, 2003 11:29 AM:
> > #ifdef _PATH_DEFPATH
> > #undef _PATH_DEFPATH
> > #define _PATH_DEFPATH
> > "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WIN
> > DOWS/system32/Wbem" #endif
> > 
> > which contains both, NT and 9x paths.  We could perhaps even
> > change /usr/include/paths.h to reflect this, at one point.
> 
> Just one side note: Are you sure, that the orthography of all these subdirectories 
> is the same for all Windows plattforms (at least with VFAT or NTFS)? You might get 
> problems with the strict setting otherwise.

The above given paths are the sum of the minimal paths given on
9x and NT.  /WINDOWS is given on both, /WINDOWS/COMMAND is given
on 9x/Me, /WINDOWS/system32 and /WINDOWS/system32/Wbem are the paths
on NT systems.  I don't see a need so far to extend these paths
since $PATH doesn't need to have all paths you can think of, but
the minimal paths which allow to run applications from a subprocess
of a daemon.  The important paths are the ones which contain DLLs,
not even the paths to Windows native commands are really necessary
for that.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: /WINDOWS

2003-12-08 Thread Christopher Faylor

On Mon, Dec 08, 2003 at 01:27:30PM +0100, Corinna Vinschen wrote:
>On Dec  8 14:14, Ronald Landheer-Cieslak wrote:
>> Good idea, except that I'd personally prefer a mount point in stead of a 
>> symlink but that's just personal preference.. (Personally, I'd prefer that
>> the Cygwin DLL make /WINDOWS a "magical" mountpoint to the likeness of 
>> /dev, /proc, etc. so as to make it completely transparent and make sure no
>> user can "accidentally" remove the symlink, so as to make sure that the
>> programs can actually rely on it being there and on it to behave as a "normal"
>> directory..)
>
>Yes, that's a good idea, too.  And it also would remove a potential
>security problem if anybody could redirect the /WINDOWS link to some
>tainted directory.

Except that we're going to be moving away from magical mountpoints now that
mknod works.

cgf

Re: /WINDOWS

On Dec  8 11:06, Christopher Faylor wrote:
> On Mon, Dec 08, 2003 at 01:27:30PM +0100, Corinna Vinschen wrote:
> >On Dec  8 14:14, Ronald Landheer-Cieslak wrote:
> >> Good idea, except that I'd personally prefer a mount point in stead of a 
> >> symlink but that's just personal preference.. (Personally, I'd prefer that
> >> the Cygwin DLL make /WINDOWS a "magical" mountpoint to the likeness of 
> >> /dev, /proc, etc. so as to make it completely transparent and make sure no
> >> user can "accidentally" remove the symlink, so as to make sure that the
> >> programs can actually rely on it being there and on it to behave as a "normal"
> >> directory..)
> >
> >Yes, that's a good idea, too.  And it also would remove a potential
> >security problem if anybody could redirect the /WINDOWS link to some
> >tainted directory.
> 
> Except that we're going to be moving away from magical mountpoints now that
> mknod works.

So, what's your suggestion?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: /WINDOWS

2003-12-08 Thread Christopher Faylor

On Mon, Dec 08, 2003 at 05:15:01PM +0100, Corinna Vinschen wrote:
>On Dec  8 11:06, Christopher Faylor wrote:
>> On Mon, Dec 08, 2003 at 01:27:30PM +0100, Corinna Vinschen wrote:
>> >On Dec  8 14:14, Ronald Landheer-Cieslak wrote:
>> >> Good idea, except that I'd personally prefer a mount point in stead of a 
>> >> symlink but that's just personal preference.. (Personally, I'd prefer that
>> >> the Cygwin DLL make /WINDOWS a "magical" mountpoint to the likeness of 
>> >> /dev, /proc, etc. so as to make it completely transparent and make sure no
>> >> user can "accidentally" remove the symlink, so as to make sure that the
>> >> programs can actually rely on it being there and on it to behave as a "normal"
>> >> directory..)
>> >
>> >Yes, that's a good idea, too.  And it also would remove a potential
>> >security problem if anybody could redirect the /WINDOWS link to some
>> >tainted directory.
>> 
>> Except that we're going to be moving away from magical mountpoints now that
>> mknod works.
>
>So, what's your suggestion?

Don't bog cygwin down with more magical "mount points".  Other than that, I have
no suggestion.

RE: /WINDOWS

2003-12-08 Thread Jörg Schaible

Corinna Vinschen wrote on Monday, December 08, 2003 4:42 PM:
>> Just one side note: Are you sure, that the orthography of all these
>> subdirectories is the same for all Windows plattforms (at least with
>> VFAT or NTFS)? You might get problems with the strict setting
>> otherwise.
> 
> The above given paths are the sum of the minimal paths given
> on 9x and NT.  /WINDOWS is given on both, /WINDOWS/COMMAND is
> given on 9x/Me, /WINDOWS/system32 and /WINDOWS/system32/Wbem
> are the paths on NT systems.  I don't see a need so far to
> extend these paths since $PATH doesn't need to have all paths
> you can think of, but the minimal paths which allow to run
> applications from a subprocess of a daemon.  The important
> paths are the ones which contain DLLs, not even the paths to
> Windows native commands are really necessary for that.

Yeah, that's clear, but I thought back at the time I tinkered with "strict" myself. At 
that time cygpath -S just returned the value of GetWindowsDirectory(), but 
unfortunately the physical entry on the disk was different concerning case. IIRC 
GetSystemDirectory delivered "C:\WinNT\Sytem32" for my system, but e.g. `cygpath 
-S`/ping with "strict" failed because in reality it was "C:\WinNT\system32". Therefore 
I've implemented in cygpath an additional lookup with GetFirstFile. The structure 
filled with this call had luckily the name of the directory with the real orthography. 
Since I believe you've seen more Windows versions than me (and my job does no longer 
force me to keep track of portability issues for the different Windows versions), I 
just want to point out, that you cannot rely on the Windows system calls concerning 
orthography. Additionally I am not sure if e.g. /WINDOWS/system32/Wbem is the really 
the same for all NT systems or if some have /WINDOWS/System32/wbem. For "strict" this 
matters though if you hard-code them.

Regards,
Jörg

Re: /WINDOWS

On Mon, 8 Dec 2003, Corinna Vinschen wrote:

> On Dec  8 08:41, Igor Pechtchanski wrote:
> > FWIW, I agree that it's a good idea to have a fixed pointer to the windows
> > directory, but I don't think "/" is the right place to have it.  Could we
> > make it "/mnt/WINDOWS" or "/opt/WINDOWS" or something?  I don't like
> > cluttering up the root directory unnecessarily...
> >   Igor
>
> I don't agree that we should move the /WINDOWS directory into some
> subdir since it's a pretty important path and doesn't have to be
> hidden artificially.  In turn I could ask why you want to clutter
> the root directory with something like /mnt.
>
> Corinna

Well, /mnt *is* in the FHS 2.2, and that's the way Linux does it --
/mnt/windows is the mount point for a Windows drive...  Since we're trying
to isolate the Windows world from the Cygwin world, or, at least, make it
seem like a separate filesystem, perhaps using the /mnt directory (like
Linux has) would be a good idea.  Or, since our drives are all sitting in
/cygdrive, perhaps /cygdrive/WINDOWS would be another alternative.
There's just something wrong with /WINDOWS, IMHO, even though I can't
quite put my finger on it.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: /WINDOWS

2003-12-08 Thread Christopher Faylor

On Mon, Dec 08, 2003 at 12:54:14PM -0500, Igor Pechtchanski wrote:
>perhaps /cygdrive/WINDOWS would be another alternative.

Let me say it more clearly -- there will be no magic in cygwin1.dll for
this.

cgf

Re: [ITP] ddd-3.3.8

2003-12-08 Thread Mark Blackburn

Harold,

How do you generate setup.ini? Is there a script somewhere or do you 
generate it by hand?

Mark Blackburn

Harold L Hunt II wrote:

I would like to contribute and maintain ddd:

http://www.gnu.org/software/ddd/

GNU DDD is a graphical front-end for command-line debuggers such as
GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, or the Python
debugger. Besides ``usual'' front-end features such as viewing source
texts, DDD has become famous through its interactive graphical data
display, where data structures are displayed as graphs.
You can point Cygwin's setup.exe to the following address to install 
and test ddd:

http://www.egr.msu.edu/~huntharo/cygwin/

***Reviewer's Caveat***: I don't think that the static libiberty.a is 
supposed to be installed, so I removed the /usr/lib directory in the 
install step of the build script.

 cut here --

#!/bin/bash

mkdir ddd
cd ddd
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1-src.tar.bz2 

 cut here --

MD5 sums:

de2d743b95817745c4227427afec759b *ddd/ddd-3.3.8-1-src.tar.bz2
86cc2b9dff9a4f794dfc6bbe49bf2bbc *ddd/ddd-3.3.8-1.tar.bz2
2c6bec0f95a7c76ee6581133eeab1db6 *ddd/setup.hint
Harold

Re: /WINDOWS

On Mon, 8 Dec 2003, Christopher Faylor wrote:

> On Mon, Dec 08, 2003 at 12:54:14PM -0500, Igor Pechtchanski wrote:
> >perhaps /cygdrive/WINDOWS would be another alternative.
>
> Let me say it more clearly -- there will be no magic in cygwin1.dll for
> this.
>
> cgf

As I see it, there is no conceptual difference between $SystemRoot and a
drive, hence I suggested /cygdrive/WINDOWS.  If /cygdrive is inherently
magical, then that presents a problem.  If it isn't, then whatever
mechanisms are used to create /cygdrive/c (mknod, mounts, magic, etc) can
be used for this as well (IMO).
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

[Review] ddd-3.3.8

2003-12-08 Thread Dr. Volker Zell

> "Harold" == Harold L Hunt,  writes:

Harold> Ronald,
Harold> Did you point setup.exe to the address given, install it, and run it? 
Harold> If so, that would be enough of a review for me.  I just want to make
Harold> sure it works on someone else's installation.

I just downloaded the source. It configures, compiles, installs and runs fine.
In the cygwin readme file the filelist is missing.

Harold> Harold

Ciao
  Volker

libsmi-0.4.2 [Re: Pending Packages List, 2003-12-05]

[I haven't heard from Abe yet regarding this package, so I am just going 
to post it as-is within a few hours unless someone requests that I not 
do that.]

I fixed the "Lib" category in the setup.hint file, which should have 
been "Libs".

You can point Cygwin's setup.exe to the following address to install and
test libsmi:
http://www.egr.msu.edu/~huntharo/cygwin/

 cut here --

#!/bin/bash

mkdir libsmi
cd libsmi
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/libsmi/libsmi-0.4.2-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/libsmi/libsmi-0.4.2-1-src.tar.bz2
 cut here --

MD5 sums:

934c299c75b8368e8dd2073c6feec8e3 *./libsmi-0.4.2-1-src.tar.bz2
c8718a2a5a14b66130328f5451b09cf9 *./libsmi-0.4.2-1.tar.bz2
e90d030f4e5d3c38e5a65ed1342e1035 *./setup.hint
Harold

[ITP - Ready for review 2] GraphicsMagick

[This is an update that needs to be reviewed again.]

I would like to contribute and maintain GraphicsMagick:

http://www.graphicsmagick.org/

Tester's Notes
==
You can point Cygwin's setup.exe to the following address to download
and test the GraphicsMagick package:
http://www.egr.msu.edu/~huntharo/cygwin/

Reviewer's Notes

1) I updated to the repaired 1.0.4 source tarball, which is 600 KB 
larger than the messed up 1.0.4 tarball (which was actually the 1.0 
release).

2) I excluded configure from the 'mkpatch' step and added 'autoconf' to 
the 'prep' step to avoid sending the configure script in the patch.

3) I moved /usr/lib/GraphicsMagick-1.0.4 into the libGraphicsMagick0 
package.

4) I notified Bob F. that an empty /usr/include/magick directory is 
being created and added a deletion of this empty directory to the 
'install' step, to be used until the upstream build system is fixed to 
stop creating this directory.

 cut here --
#!/bin/bash
mkdir GraphicsMagick
cd GraphicsMagick
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/GraphicsMagick-1.0.4-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/GraphicsMagick-1.0.4-1-src.tar.bz2
mkdir libGraphicsMagick0
cd libGraphicsMagick0
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick0/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick0/libGraphicsMagick0-1.0.4-1.tar.bz2
cd ..
mkdir libGraphicsMagick-devel
cd libGraphicsMagick-devel
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick-devel/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/GraphicsMagick/libGraphicsMagick-devel/libGraphicsMagick-devel-1.0.4-1.tar.bz2
 cut here --
MD5 sums:

97d54454f6eb3097bb9c835edb162379 *./GraphicsMagick-1.0.4-1-src.tar.bz2
6a0ac065a93e28ca78fa010fe8346459 *./GraphicsMagick-1.0.4-1.tar.bz2
3e53066d1b1afc088f5584370a09a4b6 
*./libGraphicsMagick-devel/libGraphicsMagick-devel-1.0.4-1.tar.bz2
149e44c2a070ea7cea3ea52b43aba37a *./libGraphicsMagick-devel/setup.hint
8ff50a6c130f8f2c1a451dfc0b8a1d2d 
*./libGraphicsMagick0/libGraphicsMagick0-1.0.4-1.tar.bz2
cc1846262c4ce0277166d6947f71540d *./libGraphicsMagick0/setup.hint
3cb9210d7f7f7306d9b95fce981aa7cd *./setup.hint

Harold

Generating setup.ini files [Was: Re: [ITP] ddd-3.3.8]

Mark,

Mark Blackburn wrote:
Harold,

How do you generate setup.ini? Is there a script somewhere or do you 
generate it by hand?
I use the 'upset' script that is contained in Cygwin's CVS tree.  All of 
the developers use this and it is the same script that creates the 
setup.ini file for the Cygwin distribution.

I think that there is anonymous access to the tree that contains 
'upset', but that question could be answered better by a search through 
the mailing list archives, google, or by asking your question under a 
new subject (but only if you are interested in actually creating 
setup.ini files... most people are too busy to satisfy idle curiosity).

Hope that helps,

Harold

Re: [Review] ddd-3.3.8

Thanks for reviewing this Volker.  See notes below.

Dr. Volker Zell wrote:

"Harold" == Harold L Hunt,  writes:


Harold> Ronald,
Harold> Did you point setup.exe to the address given, install it, and run it? 
Harold> If so, that would be enough of a review for me.  I just want to make
Harold> sure it works on someone else's installation.

I just downloaded the source. It configures, compiles, installs and runs fine.
In the cygwin readme file the filelist is missing.
Yup, you got me... looks like I forgot to re-run 'spkg' after updating 
the file list in the readme.  New files are below.

 cut here --

#!/bin/bash

mkdir ddd
cd ddd
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/setup.hint
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1.tar.bz2
wget \
http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1-src.tar.bz2
 cut here --

MD5 Sums:

b3719958af33c22efd04f13e0de68e84 *./ddd-3.3.8-1-src.tar.bz2
f3244afe271984c1fc1855203cb92300 *./ddd-3.3.8-1.tar.bz2
2c6bec0f95a7c76ee6581133eeab1db6 *./setup.hint
Harold

upset and the setup.exe package server

2003-12-08 Thread Joshua Daniel Franklin

I know that it doesn't come up very often, but we have had the 
occasional question about upset before Mark's. For the last while
I've been jotting things down and this got me to put up a web page
about the "Package Server", how to create a local mirror, and how
to create a custom mirror at:



I'm not sure if there would be a good place for this sort of thing in
the User's Guide, especially since it references many non-Cygwin things
(Archive::Tar, netselect), but maybe it would be useful on the website
somewhere?

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: upset and the setup.exe package server