BGINFO4X sent the following at Tuesday, July 09, 2013 6:39 AM
>Regarding to the fstab format, I don't know if it is supported, but it
>would be nice to support Environment Variables.
>
>For example, Instead of: C:/Users /desktop
>
>Use: %USERPROFILE% /desktop
>
>It is only a suggestion/example.
As
Hello,
Regarding to the fstab format, I don't know if it is supported, but it
would be nice to support Environment Variables.
For example, Instead of:
C:/Users/desktop
Use:
%USERPROFILE% /desktop
It is only a suggestion/example.
Regards.
##
>>> >> >> >> {
>>> >> >> >> - cha
On Thu, Jul 04, 2013 at 02:16:17PM +0200, Corinna Vinschen wrote:
>On Jul 4 13:45, Alexey Pavlov wrote:
>> 2013/7/4 Corinna Vinschen:
>> > On Jul 4 14:23, Alexey Pavlov wrote:
>> >> 2013/7/4 Corinna Vinschen:
>> >> > On Jul 4 12:37, Alexey Pavlov wrote:
>> >> >> 2013/7/4 Corinna Vinschen:
>> >>
?
That's an interesting idea but I don't think anyone was proposing that.
Any suggestion how this could work?
Badly, now that I think about it. Say you're in cygwin-proper bash
session, and you launch a cygwin-msys-linked exe, or a native tool --
and pass a pathname to it as an a
On 7/4/2013 8:16 AM, Corinna Vinschen wrote:
I'm ok with that, but I think we should drop the "32" from MINGW in
the first place.
Does anybody rely on the "WOW64" in uname -s output? I just checked
the scripts in /bin in my installation and none of it seems to check
for that info.
And then aga
INE}-pc-mingw32
exit ;;
i*:MSYS*:*)
echo ${UNAME_MACHINE}-pc-msys
exit ;;
(FWIW, I'm not sure what MINGW64 is all about...)
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://
On Jul 4 13:45, Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
> > On Jul 4 14:23, Alexey Pavlov wrote:
> >> 2013/7/4 Corinna Vinschen:
> >> > On Jul 4 12:37, Alexey Pavlov wrote:
> >> >> 2013/7/4 Corinna Vinschen:
> >> >> > On Jul 4 13:09, Alexey Pavlov wrote:
> >> >> >> struct utsname
> >
2013/7/4 Corinna Vinschen:
> On Jul 4 12:34, Kai Tietz wrote:
>> 2013/7/4 Alexey Pavlov wrote:
>> > 2013/7/4 Corinna Vinschen:
>> >> On Jul 4 12:37, Alexey Pavlov wrote:
>> >>> 2013/7/4 Corinna Vinschen:
>> >>> > On Jul 4 13:09, Alexey Pavlov wrote:
>> >>> >> 2013-06-18 Alexey Pavlov
>> >>> >>
On Jul 4 12:34, Kai Tietz wrote:
> 2013/7/4 Alexey Pavlov wrote:
> > 2013/7/4 Corinna Vinschen:
> >> On Jul 4 12:37, Alexey Pavlov wrote:
> >>> 2013/7/4 Corinna Vinschen:
> >>> > On Jul 4 13:09, Alexey Pavlov wrote:
> >>> >> 2013-06-18 Alexey Pavlov
> >>> >>
> >>> >> * mount.cc: Allow using a s
2013/7/4 Corinna Vinschen:
> On Jul 4 14:23, Alexey Pavlov wrote:
>> 2013/7/4 Corinna Vinschen:
>> > On Jul 4 12:37, Alexey Pavlov wrote:
>> >> 2013/7/4 Corinna Vinschen:
>> >> > On Jul 4 13:09, Alexey Pavlov wrote:
>> >> >> 2013-06-18 Alexey Pavlov
>> >> >>
>> >> >> * mount.cc: Allow using a s
On Jul 4 14:23, Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
> > On Jul 4 12:37, Alexey Pavlov wrote:
> >> 2013/7/4 Corinna Vinschen:
> >> > On Jul 4 13:09, Alexey Pavlov wrote:
> >> >> 2013-06-18 Alexey Pavlov
> >> >>
> >> >> * mount.cc: Allow using a shortened version of mount points in
2013/7/4 Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
>> On Jul 4 12:37, Alexey Pavlov wrote:
>>> 2013/7/4 Corinna Vinschen:
>>> > On Jul 4 13:09, Alexey Pavlov wrote:
>>> >> 2013-06-18 Alexey Pavlov
>>> >>
>>> >> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
>>>
2013/7/4 Corinna Vinschen:
> On Jul 4 12:37, Alexey Pavlov wrote:
>> 2013/7/4 Corinna Vinschen:
>> > On Jul 4 13:09, Alexey Pavlov wrote:
>> >> 2013-06-18 Alexey Pavlov
>> >>
>> >> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
>> >> * utsname.h: Increase sysname fiels
On Jul 4 12:37, Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
> > On Jul 4 13:09, Alexey Pavlov wrote:
> >> 2013-06-18 Alexey Pavlov
> >>
> >> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
> >> * utsname.h: Increase sysname fiels size.
> >> * uname.cc: Allow chang
2013/7/4 Corinna Vinschen:
> On Jul 4 13:09, Alexey Pavlov wrote:
>> 2013-06-18 Alexey Pavlov
>>
>> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
>> * utsname.h: Increase sysname fiels size.
>> * uname.cc: Allow changing OS name by MSYSTEM environment variable.
>> [...
On Jul 4 13:09, Alexey Pavlov wrote:
> 2013-06-18 Alexey Pavlov
>
> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
> * utsname.h: Increase sysname fiels size.
> * uname.cc: Allow changing OS name by MSYSTEM environment variable.
> [...SNIP...]
Can we please move patch
On Jul 4 13:07, Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
> > Hi Alexey,
> >
> > On Jul 4 06:33, Alexey Pavlov wrote:
> >> My opinion is to extend Cygwin parser to read msys-like mounts. It's
> >> very simple:
> >>
> >> --
2013-06-18 Alexey Pavlov
* mount.cc: Allow using a shortened version of mount points in /etc/fstab
* utsname.h: Increase sysname fiels size.
* uname.cc: Allow changing OS name by MSYSTEM environment variable.
Index: cygwin/mount.cc
2013/7/4 Corinna Vinschen:
> Hi Alexey,
>
> On Jul 4 06:33, Alexey Pavlov wrote:
>> My opinion is to extend Cygwin parser to read msys-like mounts. It's
>> very simple:
>>
>> --- mount.cc 2013-04-24 20:29:29.0 +0400
>> +++ Cygwin/winsup/cygwin/
Hi Alexey,
On Jul 4 06:33, Alexey Pavlov wrote:
> My opinion is to extend Cygwin parser to read msys-like mounts. It's
> very simple:
>
> --- mount.cc 2013-04-24 20:29:29.0 +0400
> +++ Cygwin/winsup/cygwin/mount.cc 2013-06-13 09:35:01.479492100 +0400
> @@ -112
be able read short mount points from fstab:
> >>> .
> >>> All other options are set by default. With my changes I can have in
> >>> /etc/fstab both types of mount points - cygwin-like and msys-like.
> >>
> >> And why is that necessary? There a
My opinion is to extend Cygwin parser to read msys-like mounts. It's
very simple:
--- mount.cc 2013-04-24 20:29:29.0 +0400
+++ Cygwin/winsup/cygwin/mount.cc 2013-06-13 09:35:01.479492100 +0400
@@ -1125,8 +1118,17 @@
if (!*c)
return true;
cend = find_ws (c);
- *cend
don't think anyone was proposing that.
Is there any reason why we'd need to add a hook to filename parsing?
That would be an alternative to hooking fstab.
Well, MSYS doesn't mind dos-style filenames, so the big-ugly-warn-once
thing shouldn't happen... And if we ever do, really
t; All other options are set by default. With my changes I can have in
>>> /etc/fstab both types of mount points - cygwin-like and msys-like.
>>
>> And why is that necessary? There are always default options set anyway,
>> but a layout change of the fstab file simply m
msys-like.
And why is that necessary? There are always default options set anyway,
but a layout change of the fstab file simply makes no sense. There's no
win at all.
I think Alexey is trying to replicate MSYS's behavior, so it becomes
more of a drop-in replacement. Here'
On Jul 3 22:24, Alexey Pavlov wrote:
> 2013/7/3 Christopher Faylor:
> > On Wed, Jul 03, 2013 at 08:03:25PM +0400, Alexey Pavlov wrote:
> >>I want to continue our discussion about integrating MSYS mode into
> >>Cygwin sources.
> >>Right now we need to determine
2013/7/3 Christopher Faylor:
> On Wed, Jul 03, 2013 at 08:03:25PM +0400, Alexey Pavlov wrote:
>>I want to continue our discussion about integrating MSYS mode into
>>Cygwin sources.
>>Right now we need to determine where you can create hooks for msys
>>plugin I think
On Wed, Jul 03, 2013 at 08:03:25PM +0400, Alexey Pavlov wrote:
>I want to continue our discussion about integrating MSYS mode into
>Cygwin sources.
>Right now we need to determine where you can create hooks for msys
>plugin I think.
>MSYS plugin need to has ability to ch
I want to continue our discussion about integrating MSYS mode into
Cygwin sources.
Right now we need to determine where you can create hooks for msys
plugin I think.
MSYS plugin need to has ability to change next logic:
- generating osname
- reading /etc/fstab
- changing environment variables
On Tue, Jun 25, 2013 at 5:02 AM, Csaba Raduly wrote:
> On Mon, Jun 24, 2013 at 1:55 PM, Corinna Vinschen wrote:
>> On Jun 24 07:03, Earnie Boyd wrote:
>>> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>>> >
>>> > Using another build system doesn't mean you can't switch to the better
>>>
On Mon, Jun 24, 2013 at 1:55 PM, Corinna Vinschen wrote:
> On Jun 24 07:03, Earnie Boyd wrote:
>> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>> >
>> > Using another build system doesn't mean you can't switch to the better
>> > one.
>>
>> That depends on one's view of better and Chris
On Jun 24 07:03, Earnie Boyd wrote:
> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
> >
> > Using another build system doesn't mean you can't switch to the better
> > one.
>
> That depends on one's view of better and Chris already believes he
> uses the better one. That is why is refus
On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>
> Using another build system doesn't mean you can't switch to the better
> one.
That depends on one's view of better and Chris already believes he
uses the better one. That is why is refuses to use something else.
--
Earnie
-- https://s
On Jun 21 10:34, Christopher Faylor wrote:
> On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
> >On Jun 20 22:38, Andrew Schulman wrote:
> >> > If every maintainer would use cygport, it would allow us to change
> >> > the build method to one along the lines of most Linux distro
On Fri, Jun 21, 2013 at 04:03:46PM -0400, Andrew Schulman wrote:
>>On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>>>On Jun 20 22:38, Andrew Schulman wrote:
>If every maintainer would use cygport, it would allow us to change the
>build method to one along the lines of mos
> On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
> >On Jun 20 22:38, Andrew Schulman wrote:
> >> > If every maintainer would use cygport, it would allow us to change
> >> > the build method to one along the lines of most Linux distros.
> >> > In Linux distros, the maintaine
On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>On Jun 20 22:38, Andrew Schulman wrote:
>> > If every maintainer would use cygport, it would allow us to change
>> > the build method to one along the lines of most Linux distros.
>> > In Linux distros, the maintainer provides
On Jun 20 22:38, Andrew Schulman wrote:
> > If every maintainer would use cygport, it would allow us to change
> > the build method to one along the lines of most Linux distros.
> > In Linux distros, the maintainer provides only the spec file and
> > the source archive. The actual build fo
> If every maintainer would use cygport, it would allow us to change
> the build method to one along the lines of most Linux distros.
> In Linux distros, the maintainer provides only the spec file and
> the source archive. The actual build for all supported platforms
> could be done on
On Jun 20 11:43, Warren Young wrote:
> On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote:
> >On 2013-06-19 12:57, Warren Young wrote:
> >>You're not talking about anything different than the sort of thing
> >>Cygwin package maintainers go through, sometimes needing to arm-twist
> >>odd build systems to b
On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote:
On 2013-06-19 12:57, Warren Young wrote:
You're not talking about anything different than the sort of thing
Cygwin package maintainers go through, sometimes needing to arm-twist
odd build systems to behave according to cygport's expectations?
I thin
forementioned uname(3) thing. (One of the "deltas" between cygwin and
> > msys was msys used a really stupid ownership/permission model -- pretend
> > current user owns everything; check the DOS R/O bit for +w; check the file
> > extension for +x; -- but this can be a
On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote:
>
> I assume that, eventually and as-needed, a *small* number of additional
> "hooks" could be added to other code paths than exec/spawn/etc -- such as
> the aforementioned uname(3) thing. (One of the "deltas&quo
On 6/19/2013 1:45 PM, Christopher Faylor wrote:
I'm talking about providing hooks so that an add-on MSYS dll could
modify the windows command-line. Then we wouldn't care what MSYS does
with the command-line since it isn't a Cygwin DLL decision. The goal is
to allow a small D
On Jun 19 11:04, Earnie Boyd wrote:
> On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote:
> > I want to add MSYS functionality to Cygwin.
>
> One issue with that would be copyright assignment. Alexey has been in
> the MSYS code so someone who hasn't looked would need
On 2013-06-19 12:57, Warren Young wrote:
Not all packages are cross-compiler-compatible.
Is that another way of saying that not all packages use autotools? :)
autotools can certainly make cross-compiling easier than most other
build systems, but it's not a guarantee either. For instance, an
On 6/19/2013 07:31, Charles Wilson wrote:
http://www.mingw.org/wiki/Posix_path_conversion
That's good info.
I'm glad to see that relative paths are never molested. I tried for a
while to confuse Cygwin and native Windows programs using relative
paths, and failed to find a case where the pa
ant to cope with my contrived "xcopy /bin a b"
>example? The point of the example, of course, is that "/bin" looks like
>a real, existing POSIX path, but isn't.
I don't think people are getting this:
*How this is implemented doesn't matter*.
I'm
On Jun 19 10:53, Warren Young wrote:
> On 6/19/2013 03:05, Corinna Vinschen wrote:
> >
> >Done. Please have a look:
> >http://cygwin.com/faq.html#faq.using.multiple-copies
> >http://cygwin.com/faq.html#faq.using.third-party.multiple-copies
>
> Thanks!
>
> It looks like 4.22 is still out of date,
st, I don't have any
objection to making exec() take longer for the native Windows case only.
Do you know how you want to cope with my contrived "xcopy /bin a b"
example? The point of the example, of course, is that "/bin" looks like
a real, existing POSIX path, but isn
On 6/19/2013 03:05, Corinna Vinschen wrote:
Done. Please have a look:
http://cygwin.com/faq.html#faq.using.multiple-copies
http://cygwin.com/faq.html#faq.using.third-party.multiple-copies
Thanks!
It looks like 4.22 is still out of date, though. The "must be run
serially" bit, at least, con
On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote:
> I want to add MSYS functionality to Cygwin.
One issue with that would be copyright assignment. Alexey has been in
the MSYS code so someone who hasn't looked would need to implement
similar functionality.
--
Earnie
On 6/18/2013 10:05 PM, Christopher Faylor wrote:
Let me state it again: Corinna and I have been having private discussion
about this and are open to talking about the possibility of adding
MSYS capability to Cygwin. I'm advocating adding hooks to the DLL
which would accomplish that.
exec() expensive, too, with
predictable consequences to overall system speed.
I don't see how Cygwin couldn't afford to behave this way by default.
Maybe as an option?
This is what MSYS-1 does. If the executable depends on the msys dll,
then no path translation is done. If the executable doe
2013/6/19 Corinna Vinschen :
> On Jun 19 10:53, Алексей Павлов wrote:
>> Today I investigate in this direction and find that logic works well
>> except one line in spawn.cc that I think can be fixed without break
>> anything.
>>
>> Index: cygwin/spawn.cc
>> =
On Jun 19 10:53, Алексей Павлов wrote:
> Today I investigate in this direction and find that logic works well
> except one line in spawn.cc that I think can be fixed without break
> anything.
>
> Index: cygwin/spawn.cc
> ===
> RCS fil
On Jun 19 10:15, Corinna Vinschen wrote:
> On Jun 18 22:03, Christopher Faylor wrote:
> > On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
> > >On 6/18/2013 13:31, Christopher Faylor wrote:
> > >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young w
On Jun 18 22:03, Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
> >On 6/18/2013 13:31, Christopher Faylor wrote:
> >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
> >>>> 3. In MSYS mode Cygwin need to be v
I want point all who read this ML to mingw-w64 ML discussion about MSYS:
http://sourceforge.net/mailarchive/message.php?msg_id=31008339
Also I want to say that all changes that I do in Cygwin DLL (except
symlink-copy) do not break any Cygwin stuff and only applied to
non-cygwin applications. For
2013/6/19 Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>>On 6/18/2013 13:30, ??? ?? wrote:
>>> 2013/6/18 Warren Young :
On 6/18/2013 12:40, ??? ?? wrote:
>
> 1. The correct definition of executables belonging to Cygwin DLL.
>
on
about this and are open to talking about the possibility of adding
MSYS capability to Cygwin. I'm advocating adding hooks to the DLL
which would accomplish that.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
>On 6/18/2013 13:31, Christopher Faylor wrote:
>> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>>>> 3. In MSYS mode Cygwin need to be very portable
>>>
>>> It would indeed be n
On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>On 6/18/2013 13:30, ??? ?? wrote:
>> 2013/6/18 Warren Young :
>>> On 6/18/2013 12:40, ??? ?? wrote:
1. The correct definition of executables belonging to Cygwin DLL.
>>>
>>> Can you give an example of what you
On 6/18/2013 16:04, Warren Young wrote:
You're proposing some kind of global search-and-replace
operation, which will inevitably turn into a Whac-a-Mole game.
I just thought of an example. How many POSIX paths are in this
perfectly legal command, which invokes a native Windows executable?
On 6/18/2013 16:04, Warren Young wrote:
$ cd /bin
$ mv ln.exe sane-ln.exe
$ ln -s cp.exe ln.exe
Of course, that final step should be
$ cp cp.exe ln.exe
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
ons in /etc/fstab - only win32_path and
posix_path.
Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.
I don't see why that's Cygwin's concern.
It should be sufficient for Cygwin to provides a reasonable path
forward, so that those re
On 6/18/2013 2:40 PM, Алексей Павлов wrote:
I want to add MSYS functionality to Cygwin.
More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
MSYS is very old and don't has any support for it.
...
I want to hear your opinions about how it can be implemented in Cygwin cod
On 6/18/2013 13:31, Christopher Faylor wrote:
On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
3. In MSYS mode Cygwin need to be very portable
It would indeed be nice to have a portable Cygwin. That is, one that
could be run from a copied directory or USB key, without being
executables?
>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>I don't see how Cygwin can reliably predict when and whether to do this.
> That is why it provides cygpath(1). You, the user, use that tool when
cygwin paths and can't
use it. For example, you cannot do something like this on Cygwin:
notepad /home/user/mydoc.txt
Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.
>> 3. In MSYS mode Cygwin need to be very portabl
3. In MSYS mode Cygwin need to be very portable
It would indeed be nice to have a portable Cygwin. That is, one that
could be run from a copied directory or USB key, without being formally
installed. Such a thing would need to solve the 3PP problem, though,
which is Hard (tm).
4. Abili
On Tue, Jun 18, 2013 at 10:40:36PM +0400, ??? ?? wrote:
>Hi everybody!
>
>I want to add MSYS functionality to Cygwin.
>More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
>MSYS is very old and don't has any support for it.
>Primary goal of MSYS is to p
Hi everybody!
I want to add MSYS functionality to Cygwin.
More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
MSYS is very old and don't has any support for it.
Primary goal of MSYS is to provide environment with GNU utilities for
building application using native Mingw comp
On 02.05.2013 10:05, Sebastian Schuberth wrote:
here's a small patch against the rebase 4.4.0-1 package to the rebaseall / peflagsall
scripts that avoid talking about "cygwin" when running under MSYS / MinGW to
not confuse the user.
Any comments on the patch?
--
Seba
Hi,
here's a small patch against the rebase 4.4.0-1 package to the rebaseall /
peflagsall scripts that avoid talking about "cygwin" when running under MSYS /
MinGW to not confuse the user.
diff -Nur a/peflagsall.in b/peflagsall.in
--- a/peflagsall.in Mon Apr 30 15:3
> What Csaba said. Also, MSYS's bin directory does appear in there
> (/cygdrive/c/msys/1.0/bin), but Cygwin's is before it, so that's fine.
> Hence, as mentioned before, you need to check whether you do actually
> have Cygwin's vi and make installed, e.g. usi
On Mon, Nov 29, 2010 at 09:51:19AM +, Andy Koppe wrote:
>What Csaba said. Also, MSYS's bin directory does appear in there
>(/cygdrive/c/msys/1.0/bin), but Cygwin's is before it, so that's fine.
>Hence, as mentioned before, you need to check whether you do actually
&g
munications
> Security\
> SSH Secure Shell;Z:.;Y:.;
>
> Cygwin:
> /usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/System32:/cygdrive/c/WINDOWS:/c
> ygdrive/c/WINDOWS/SYSTEM32/Wbem:/cygdrive/c/Program
> Files/Novell/ZENworks/:/cygd
> rive/c/Program
> Files/QuickTime/
/WINDOWS/SYSTEM32/Wbem:/cygdrive/c/Program
> Files/Novell/ZENworks/:/cygd
> rive/c/Program
> Files/QuickTime/QTSystem/:/cygdrive/c/MinGW/bin:/usr/bin:/cygdriv
> e/c/msys/1.0/bin:/cygdrive/c/Program
> Files/TortoiseSVN/bin:/cygdrive/c/Program F
> iles/Novell/GroupWise:/cygdrive/
EM32/Wbem:/cygdrive/c/Program Files/Novell/ZENworks/:/cygd
rive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/MinGW/bin:/usr/bin:/cygdriv
e/c/msys/1.0/bin:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program F
iles/Novell/GroupWise:/cygdrive/c/Program Files/Putty:/cygdrive/c/GTK/2.0/bi
On 29 November 2010 04:18, Nathan Rose wrote:
> I have just installed Cygwin on my WinXP box for the first time. I already
> had MSYS installed. They are installed in the directories C:\cygwin and
> C:\msys respectively.
>
> Simple file operations like cp or mv work fine within C
I have just installed Cygwin on my WinXP box for the first time. I already had
MSYS installed. They are installed in the directories C:\cygwin and C:\msys
respectively.
Simple file operations like cp or mv work fine within Cygwin . However, when I
try to open a file with vi, it opens the
On Aug 12 17:09, Chiheng Xu wrote:
> On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake wrote:
> > On 08/09/2010 07:19 PM, Chiheng Xu wrote:
> >> As far as I know, Cygwin now use Windows shortcut to implement
> >> symlink. This work well with native apps.
> >
> > Not true. Cygwin can read windows shortc
On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake wrote:
> On 08/09/2010 07:19 PM, Chiheng Xu wrote:
>> As far as I know, Cygwin now use Windows shortcut to implement
>> symlink. This work well with native apps.
>
> Not true. Cygwin can read windows shortcuts as symlinks, but does not
> generate window
On 08/09/2010 07:19 PM, Chiheng Xu wrote:
> As far as I know, Cygwin has dropped text mode in 1.7, only providing
> binary mode. This make Cygwin more like an real Linux environment. I
> think this is because many Unix tools can not work perfectly at text
> mode.
Not true. But you are correct tha
On Tue, Aug 10, 2010 at 1:25 AM, Earnie wrote:
> Chiheng Xu wrote:
>>
>> On Fri, Jul 30, 2010 at 10:50 AM, Chiheng Xu
>> wrote:
>> >
>> > Is 64-bits MSYS or Cygwin necessary?
>> >
>> > MSYS may be not necessary at all.
>>
Quoting Ali Irfan Ustek :
Hi all,
I installed Msys to test MingW and uninstalled them both. However now
my HOME path is set to /cygdrive/c/msys/1.0/home and I can't get my
home directory back.
No idea as to why this has happened. But please have a look at
/etc/profile. This file
Hi all,
I installed Msys to test MingW and uninstalled them both. However now
my HOME path is set to /cygdrive/c/msys/1.0/home and I can't get my
home directory back.
Any Ideas?
Thanks,
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.co
Ok, thanks. I have reported it as a mingw bug then.
On Tue, Jun 9, 2009 at 2:22 AM, Christopher
Faylor wrote:
> On Mon, Jun 08, 2009 at 11:33:42PM +0200, Lennart Borgman wrote:
>>After installing cygwin 1.7 beta I tried to start msys sh (which I
>>have not been doing for a long wh
On Mon, Jun 08, 2009 at 11:33:42PM +0200, Lennart Borgman wrote:
>After installing cygwin 1.7 beta I tried to start msys sh (which I
>have not been doing for a long while). I got the following error:
>
> @c:\msys\1.0\bin\sh --login %*
> AllocationBase 0x0, BaseAddress 0x715B0
After installing cygwin 1.7 beta I tried to start msys sh (which I
have not been doing for a long while). I got the following error:
@c:\msys\1.0\bin\sh --login %*
AllocationBase 0x0, BaseAddress 0x715B, RegionSize 0x15, State 0x1
c:\msys\1.0\bin\sh.exe: *** Couldn't re
On Thu, Dec 07, 2006 at 09:27:19AM -0500, Bob Rossi wrote:
>On Thu, Dec 07, 2006 at 09:19:04AM -0500, Buchbinder, Barry (NIH/NIAID) [E]
>wrote:
>> Bob Rossi wrote on Thursday, December 07, 2006 9:10 AM:
>> > I'd like to know if anyone knows if it is possible to start
On Dec 7 09:27, Bob Rossi wrote:
> However, when I'm remote,
> there is no way I can see to get into an msys environment.
>
> The mingw-users list suggested that I get another version of sshd that's
> not related to cygwin. However, i like cygwin's sshd serv
On Thu, Dec 07, 2006 at 09:19:04AM -0500, Buchbinder, Barry (NIH/NIAID) [E]
wrote:
> Bob Rossi wrote on Thursday, December 07, 2006 9:10 AM:
> > I'd like to know if anyone knows if it is possible to start the msys
> > environment from a cygwin shell? I'm ssh'ing int
Bob Rossi wrote on Thursday, December 07, 2006 9:10 AM:
> I'd like to know if anyone knows if it is possible to start the msys
> environment from a cygwin shell? I'm ssh'ing into a windows machine,
> which gives me a cygwin shell. I've tried a lot of things, and ca
Hi,
I'd like to know if anyone knows if it is possible to start the msys
environment from a cygwin shell? I'm ssh'ing into a windows machine,
which gives me a cygwin shell. I've tried a lot of things, and can't get
an msys environment.
Even if I remove every environmen
On 01 September 2006 08:37, Schwarz, Konrad wrote:
> $ nslookup localhost
> Server: mail2.siemens.de
> Address: 139.25.208.11
>
> Non-authoritative answer:
> Name:localhost.ww002.siemens.net
> Address: 127.0.0.1
>
> $
>
> which is weird, I shouldn't have thought that nslookup return a po
> >> By the way, any idea why //localhost/C$ doesn't work?
> > do you have
> > 127.0.0.1 localhost
> > in your hosts file ?
Yes, localhost is in %SystemRoot%\System32\etc\drivers\hosts.
> No, I don't think that's it. This is netbios name
> resolution and DNS doesn't come into it; it's resol
Schwarz, Konrad wrote:
Also, someone called Interix a POS, which I can't find on
http://cygwin.com/acronyms, but I guess is derogatory (I originally
though "POsix Simulation" or something, to tell the truth). Is there a
list of reasons of the drawbacks of Interix somewhere?
Um, yeah, that woul
On 30 August 2006 16:43, Samuel Thibault wrote:
> Schwarz, Konrad, le Wed 30 Aug 2006 17:39:48 +0200, a écrit :
>> By the way, any idea why //localhost/C$ doesn't work?
>
> do you have
> 127.0.0.1 localhost
> in your hosts file ?
>
No, I don't think that's it. This is netbios name resolution
1 - 100 of 111 matches
Mail list logo
