On 8/26/2016 10:58 AM, Nellis, Kenneth wrote:
> $ cmd /c DIR $(cygpath -w hello)
But
$ cmd /c $(cygpath -w hello)
will execute hello.exe
The fact that you get file not found error tells me that cmd is doing
what it does. The purpose of the .exe magic is for executing the file
from the Cyg
On Fri, Aug 26, 2016 at 10:58 AM, Nellis, Kenneth wrote:
> Here is a contrived example:
>
> $ cmd /c DIR $(cygpath -w hello.exe)
> Volume in drive C has no label.
> Volume Serial Number is 6A15-FFB2
>
> Directory of C:\cygwin\home\knellis\dev\c\hello
>
> 08/26/2016 10:4760,927 hello
the tool
should do the .exe magic rather than pass off this
responsibility to the user. Food for thought.
Sounds reasonable, but why shouldn't one have to say .exe
if they mean .exe?
That principle makes things easy.
Just to illustrate a complication of that approach:
Imagine you want to t
From: cyg Simple
> On 8/26/2016 10:35 AM, Nellis, Kenneth wrote:
> > From: Herbert Stocker
> >> On 26.08.2016 15:19, Lee Dilkie wrote:
> >>> and break everyone who has existing code to take care of this?
> >>
> >> If it is done, it should be done as an additional option, i'd say.
> >
> > Of course
On 26 August 2016 at 07:08, Nellis, Kenneth wrote:
> Dear Cygwin Community,
>
> $ ls -l
> total 60
> -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe
> $ ./hello
> Hello, world!
> $ cygpath -w hello
> hello
> $
>
> The purpose of cygpath -w, it seems to me, is to provide
> to Windows
On 8/26/2016 10:35 AM, Nellis, Kenneth wrote:
> From: Herbert Stocker
>> On 26.08.2016 15:19, Lee Dilkie wrote:
>>> and break everyone who has existing code to take care of this?
>>
>> If it is done, it should be done as an additional option, i'd say.
>
> Of course a new option, duh! ☺
> But my fe
From: Herbert Stocker
> On 26.08.2016 15:19, Lee Dilkie wrote:
> > and break everyone who has existing code to take care of this?
>
> If it is done, it should be done as an additional option, i'd say.
Of course a new option, duh! ☺
But my feeble brain is failing to imagine a case where this
would
rtainly
> be a problem. I recognize this might be considered a
> change of scope for the program, but I think the tool
> should do the .exe magic rather than pass off this
> responsibility to the user. Food for thought.
You say certainly but provide no real proof other than y
change of scope for the program, but I think the tool
should do the .exe magic rather than pass off this
responsibility to the user. Food for thought.
and break everyone who has existing code to take care of this?
If it is done, it should be done as an additional option, i'd say.
He
think the tool
should do the .exe magic rather than pass off this
responsibility to the user. Food for thought.
and break everyone who has existing code to take care of this?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
Cygwin allows to be
referenced simply as foo, should not: cygpath -w foo
return: foo.exe
instead of: foo
?
Passing foo to a Windows application will certainly
be a problem. I recognize this might be considered a
change of scope for the program, but I think the tool
should do the .exe magic rather
On Tue, Nov 05, 2013 at 03:44:35PM +1100, wrote:
>Christopher Faylor wrote:
>
>> On Tue, Nov 05, 2013 at 02:52:44AM +0400, Andrey Repin wrote:
>> >Greetings, All!
>> >
>> >$ mode
>> >mode.com modemui.dll modex.dll
>>
>> That woul
On Mon, Nov 04, 2013 at 10:58:21PM -0500, Christopher Faylor wrote:
>On Tue, Nov 05, 2013 at 02:52:44AM +0400, Andrey Repin wrote:
>>Greetings, All!
>>
>>$ mode
>>mode.com modemui.dll modex.dll
>
>That would be /bin/sh exe magic from the looks of it. It
Christopher Faylor wrote:
> On Tue, Nov 05, 2013 at 02:52:44AM +0400, Andrey Repin wrote:
> >Greetings, All!
> >
> >$ mode
> >mode.com modemui.dll modex.dll
>
> That would be /bin/sh exe magic from the looks of it. It is probably
> just trying to find
On Tue, Nov 05, 2013 at 02:52:44AM +0400, Andrey Repin wrote:
>Greetings, All!
>
>$ mode
>mode.com modemui.dll modex.dll
That would be /bin/sh exe magic from the looks of it. It is probably
just trying to find anything with an executable bit set, just like on
Linux.
>$ m
Greetings, All!
$ mode
mode.com modemui.dll modex.dll
$ mode
bash: mode: command not found
Now, I see two issues.
First, it is that it see .dll files as executables. Which is true in essence,
but rather suspicious, as .dll files are normally not directly executable.
Would really like an exp
Greetings, Al!
>> You didn't read my reply to the end, but I accept your explanation.
>> Still, that specific point of code is suspicious for my taste of
>> fool-proof'ness.
>>
> Sure you could reflect about the length of minor versions here. But
> does that address the original topic? :-)
> Aft
>
> You didn't read my reply to the end, but I accept your explanation.
> Still, that specific point of code is suspicious for my taste of
> fool-proof'ness.
>
Sure you could reflect about the length of minor versions here. But
does that address the original topic? :-)
After python 2.7 there is 3
Greetings, Rolf Campbell!
> test case---
> From bash, in an empty directory:
> $ ln /bin/ls t
> $ ls
> t.exe
>
> Why does the resulting hard link have a '.exe' suffix on it? I thought
> that cygwin .exe magic was only ap
Greetings, Al!
>> I'm fairly certain, that the script is bugged in this specific case.
>> It should be looking for python2.* instead.
>> Minor version could have any length... potentially. (And yes, I know, there
>> wouldn't be .10 for now)
> Definitly not. It would also find "python2.6-config" w
Greetings, Al!
>> For instance, this one: Either we always remove the .exe suffix from
>> a file, or we have to check for each file with a .exe suffix, whether
>> it's executable or not.
> Probably without checking it. No sane program would use the .exe
> suffix as extension of a mere textfile.
> I'm fairly certain, that the script is bugged in this specific case.
> It should be looking for python2.* instead.
> Minor version could have any length... potentially. (And yes, I know, there
> wouldn't be .10 for now)
Definitly not. It would also find "python2.6-config" which is not
wanted. It
e two types of filessystem
handling. The "normal" windows one, always with .exe suffix stored
into the filename of executables. When mounting foreign unix
filesystems no .exe magic would be used at all on them.
Al
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Greetings, Al!
> I have another interesting case where .exe magic doesn't work as
> transparently as one would expect.
> I have a file python2.6.exe. A script tries to find it with "ls
> python2.?". It is not found.
I'm fairly certain, that the script is bugged
On 9/15/2010 12:23 PM, Al wrote:
For instance, this one: Either we always remove the .exe suffix from
a file, or we have to check for each file with a .exe suffix, whether
it's executable or not.
Probably without checking it. No sane program would use the .exe
suffix as extension of a mere te
On 09/15/2010 11:03 AM, Rolf Campbell wrote:
test case---
From bash, in an empty directory:
$ ln /bin/ls t
$ ls
t.exe
Why does the resulting hard link have a '.exe' suffix on it? I thought
that cygwin .exe magic was only appending when listing a
test case---
From bash, in an empty directory:
$ ln /bin/ls t
$ ls
t.exe
Why does the resulting hard link have a '.exe' suffix on it? I thought
that cygwin .exe magic was only appending when listing a file?
--
Problem reports: http://
>
> For instance, this one: Either we always remove the .exe suffix from
> a file, or we have to check for each file with a .exe suffix, whether
> it's executable or not.
Probably without checking it. No sane program would use the .exe
suffix as extension of a mere textfile.
What would be the id
> I'd love to drop the .exe suffix from readdir(), I'm just not sure what
> unwelcome side-effects we create.
>
Yes, that's always the point. All programs would break, that are only
build against the .exe suffix. Like mine after patching it. :-)
Don't know if Cygwin has a testing state to fix tho
On Sep 15 15:50, Corinna Vinschen wrote:
> On Sep 15 15:38, Al wrote:
> > >
> > > True. In theory we would have to remove .exe and .lnk suffixes from
> > > directory listings as well, but that was never the case in Cygwin.
> > >
> > >
> >
> > That's the way it has always been... isn't a strong ar
On Sep 15 15:38, Al wrote:
> >
> > True. In theory we would have to remove .exe and .lnk suffixes from
> > directory listings as well, but that was never the case in Cygwin.
> >
> >
>
> That's the way it has always been... isn't a strong argument in development.
It wasn't an argument, it was jus
>
> True. In theory we would have to remove .exe and .lnk suffixes from
> directory listings as well, but that was never the case in Cygwin.
>
>
That's the way it has always been... isn't a strong argument in development.
I guess there are some other reasons to do it this way. If not one
should
On Sep 15 13:40, Al wrote:
> Hello,
>
> I have another interesting case where .exe magic doesn't work as
> transparently as one would expect.
>
> I have a file python2.6.exe. A script tries to find it with "ls
> python2.?". It is not found.
>
> Here th
Hello,
I have another interesting case where .exe magic doesn't work as
transparently as one would expect.
I have a file python2.6.exe. A script tries to find it with "ls
python2.?". It is not found.
Here the script needs a modification to work with Cygwin, but we can't
real
>
> I got a little bit confused now. Should I report now upstream at Perl
> that Configure
> has a problem by adding .exe, or is it just a problem with your layout?
>
> AFAIK perl does not symlink tr.exe, just its own files when using
> -Dmksymlinks.
> And failing to read a wrong tr.exe symlink do
>
> I got a little bit confused now. Should I report now upstream at Perl
> that Configure
> has a problem by adding .exe, or is it just a problem with your layout?
>
> AFAIK perl does not symlink tr.exe, just its own files when using
> -Dmksymlinks.
> And failing to read a wrong tr.exe symlink do
; /home/prefix/gentoo/bin/tr.exe
>
> Then it would proxy all available .exe magic and even Perls
> "Configure" would work.
I got a little bit confused now. Should I report now upstream at Perl
that Configure
has a problem by adding .exe, or is it just a problem with your layout?
AFAI
exe suffix itself.
Back to the starting point. It follows the sysmlink should be:
/home/prefix/gentoo/usr/bin/tr.exe -> /home/prefix/gentoo/bin/tr.exe
instead of
/home/prefix/gentoo/usr/bin/tr -> /home/prefix/gentoo/bin/tr.exe
Then it would proxy all available .exe magic and even Perls
&
> >
>
> Magic is when it does the right thing magically. With your approach
> you don't need any magic at all.
You don't seem to understand the magic here. The magic is to add the
.exe suffix to a filename. If you have a file foo.exe and call foo, you
get foo.exe. If
>
> It's definitely a bug in perl's Configure. If the name of the symlink
> is "foo", there's not the faintest reason to assume that "foo.exe" should
> work at all.
>
>
> Corinna
>
Magic is when it does the right thing magically. With your approach
you don't need any magic at all.
Al
--
Problem
7;t use the
> > .exe suffix at all.
> >
> >
>
> Right, Perl wants to be superschlau and adds the .exe suffix. That
> would work in Cygwins standard locations, where /bin and /usr/bin
> seems to be the same.
>
> Is this a Bug on the side of Perls "Configure"
ht, Perl wants to be superschlau and adds the .exe suffix. That
would work in Cygwins standard locations, where /bin and /usr/bin
seems to be the same.
Is this a Bug on the side of Perls "Configure" or rather a limitation
in Cygwins .exe magic? As there is no official standard, how to
On Sep 6 11:53, Al wrote:
> It does not:
>
> > It does:
> >
> > $ cd tmp
> > $ mkdir dir1 dir2
> > $ cp /bin/echo.exe dir1
> > $ ln -s `pwd`/dir1/echo.exe dir2/echo
> > $ ls -l dir*
> > dir1:
> > total 52
> > -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe
> >
> > dir2:
> >
It does not:
> It does:
>
> $ cd tmp
> $ mkdir dir1 dir2
> $ cp /bin/echo.exe dir1
> $ ln -s `pwd`/dir1/echo.exe dir2/echo
> $ ls -l dir*
> dir1:
> total 52
> -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe
>
> dir2:
> total 1
> lrwxrwxrwx 1 corinna vinschen 31 2010-09-06
dot, not slash?
> So we have a symblic link to an executable from a different directory.
>
> Perls configuration script detected /home/prefix/gentoo/usr/bin/tr and
> called it as /home/prefix/gentoo/usr/bin/tr.exe. That didn't work.
> Obviously the .exe magic does
>
> Sounds like you didn't run autoreconf (which would have been done
> automatically via the supported mechanism).
>
I have added the autoreconf step to the Emerge scripts.
Only one conflicts with a Gentoo patches, which I had to disable.
Works fine now. Solved all problems from that corner.
and
called it as /home/prefix/gentoo/usr/bin/tr.exe. That didn't work.
Obviously the .exe magic does not work for symbolic links from a
different directory.
I solved that by adding a second symbolic link
/home/prefix/gentoo/usr/bin/tr.exe.
What is the best way to go here?
* Adapting all scri
2010/9/3 Al :
> 2010/9/3 Al :
Right. I applied it the traditional way.
>>>
>>> Ah, you have to understand this about cygport patches: they only contain
>>> patches for the source files, not the autogenerated ones. So they have
>>> patches for e.g. Makefile.am, configure.ac; but not for confi
2010/9/3 Al :
>>> Right. I applied it the traditional way.
>>
>> Ah, you have to understand this about cygport patches: they only contain
>> patches for the source files, not the autogenerated ones. So they have
>> patches for e.g. Makefile.am, configure.ac; but not for configure or even
>> Makef
>> Right. I applied it the traditional way.
>
> Ah, you have to understand this about cygport patches: they only contain
> patches for the source files, not the autogenerated ones. So they have
> patches for e.g. Makefile.am, configure.ac; but not for configure or even
> Makefile.in. It's vitall
> Cygport is rather similar to emerge/ebuild already. You might find it
> worthwhile to give it a look.
>
I am aware of this. I want come to a solution, that builds me from
sources on any of Windows, Mac and Linux. One to rule them all. I did
only find Gentoo Prefix to be able to do this.
> If
On 9/2/2010 7:46 PM, Dave Korn wrote:
> I did once try running cygport on a linux box (with a cross-compiler). I
> don't remember exactly what went wrong, it didn't work directly out of the
> box, but it shouldn't be hard to fix.
It's only the most recent release of cygport (0.10.0) that has
ru
On 02/09/2010 21:44, Al wrote:
>> Sounds like you didn't run autoreconf (which would have been done
>> automatically via the supported mechanism).
>
> Right. I applied it the traditional way.
Ah, you have to understand this about cygport patches: they only contain
patches for the source files,
On 9/2/2010 3:44 PM, Al wrote:
>> setup.exe to download the sources and several prerequisite tools (cygport,
>> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'. Other ways
>> work, but I won't support them on this list. See also
>
> As a want to come a hybrid of Cygwin and Gentoos
> Sounds like you didn't run autoreconf (which would have been done
> automatically via the supported mechanism).
Right. I applied it the traditional way.
> setup.exe to download the sources and several prerequisite tools (cygport,
> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'.
On 09/02/2010 02:06 PM, Al wrote:
I first compiled coreutils without the cygwin patch. It did compile
but afterwards the compilation of findutils, etc. was broken. For
example configure.status of wget was truncated at the top and out of
order at the bottom. That stopped all further efforts of min
>
> Coreutils tends to be an exception, because it is so core to the system.
> Other tools that I also maintain, like m4 or findutils, port with 0
> patches.
>
Thank you. That gives me back some optimism.
I first compiled coreutils without the cygwin patch. It did compile
but afterwards the comp
On 09/02/2010 01:25 PM, Al wrote:
Hello,
I would like to estimate theexpenses to port general linux sources to
Cygwin.
I did look into Cygwins patch for coreutils. It has 1231 lines of diff
code. A lot of the stuff is related to the ".exe" magic done by
cygwin.
Do I have to
Hello,
I would like to estimate theexpenses to port general linux sources to
Cygwin.
I did look into Cygwins patch for coreutils. It has 1231 lines of diff
code. A lot of the stuff is related to the ".exe" magic done by
cygwin.
Do I have to implement that magic in this extend
reate regular file `/bin/scriptindex': File exists
$ cp -f /usr/src/xapian/xapian-omega-1.0.14a/.build/.libs/scriptindex.exe /bin/
At least --force should outsmart our .exe magic.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Problem reports: http://cygwin.com/pro
d, and you can rename it again explicitly to get the
> name you really wanted:
>
> $ ./hello.test.x
> Hello, .exe magic!
>
> ad...@ubik /tmp/exemagic
> $ ls
> hello.test.x.exe hw.c
>
> ad...@ubik /tmp/exemagic
> $ mv hello.test.x.exe hello.test.x
>
> ad
20:36 hello.x
-rw-r--r-- 1 DKAdmin None 121 May 24 20:36 hw.c
ad...@ubik /tmp/exemagic
$ ./hello.x
Hello, .exe magic!
ad...@ubik /tmp/exemagic
$ mv hello.x hello.test.x
ad...@ubik /tmp/exemagic
$ ls -la
total 125
drwxr-xr-x 1 DKAdmin None 0 May 24 20:36 .
drwxrwxrwt 1 DKAdmin None 90112 May
Dave Korn artimi.com> writes:
>
>
> Just checking: is rm supposed to ignore exe magic, then?
For now, yes. I tried it once, according to /usr/share/doc/Cygwin/coreutils-
6.9.README:
-- coreutils-5.3.0-5 -- 2005-04-14 -
Revert rm(1) implicit .exe handling, it b
Just checking: is rm supposed to ignore exe magic, then?
/artimi/software/firmware $ cp /bin/ls.exe /usr/local/bin/a2.exe
(Makes no difference if I use "cp /bin/ls /usr/local/bin/a2" either).
/artimi/software/fir
On Jun 19 02:04, Charles Wilson wrote:
> Corinna Vinschen wrote:
> >Apart from that, I don't like what libtool does. I think it's a
> >terrible idea to have a script and a binary with the same name (only
> >differing by the .exe suffix) in the same directory. This behaviour
> >breaks the CYGWIN=t
Corinna Vinschen wrote:
Apart from that, I don't like what libtool does. I think it's a
terrible idea to have a script and a binary with the same name (only
differing by the .exe suffix) in the same directory. This behaviour
breaks the CYGWIN=transparent_exe option and there's no reliable way
a
Hi Chuck,
On Apr 18 22:40, Charles Wilson wrote:
> * libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
> script writing from here...
> [func_emit_libtool_wrapper_script]: to this new function, and
> write to stdout
> [func_mode_link]: move cwrapper source code writing f
[This is a copy of a message already sent to the libtool and
libtool-patches lists. sourceware was being very picky about the
updated [Was: ...] subject line and bounced it, twice. So, I'm
resending it under the original subject line. For fear of offending the
filters again, I'm not even typ
Hello Charles, all,
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
> [added libtool to CC list]
Thanks.
> Corinna Vinschen wrote:
> >
> >Is there any chance that this could be changed in libtool?
>
> Absolutely. I outlined the steps necessary to do this:
> http://cygwin.com/ml
[added libtool to CC list]
Corinna Vinschen wrote:
On Apr 18 04:49, Charles Wilson wrote:
The current .exe behavior has benefited from many years of tweaking and
fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
automake, autoconf, libtool, bash, coreutils, ...) to work
course, we have the
same situation now for .bat files and such, it's just not as
common. (I'd rather have some flavour of PATHEXT magic than
.exe magic anyway, but I'm certainly not going to bring *that*
up.) :-) :-) :-)
In any event, I almost never get to the end of a program
. And there might be
>> some severe repurcussions in automake/autoconf where they currently are
>> coded to handle $(EXEEXT) all over the place, if they do it based on
>> hostname rather than on what the default gcc output is. I would have to
>> remove some of the .exe mag
On Apr 18 04:49, Charles Wilson wrote:
> The current .exe behavior has benefited from many years of tweaking and
> fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
> automake, autoconf, libtool, bash, coreutils, ...) to work together to
> give the current, mostly coherent
they currently are coded to handle
$(EXEEXT) all over the place, if they do it based on hostname rather than on
what the default gcc output is. I would have to remove some of the .exe magic
I've added in coreutils (but it would mean I'm closer to an upstream image).
Um, some peopl
Frank Fesevur wrote:
Larry Hall (Cygwin) wrote:
Here's a naive thought. See if it makes any sense. We have lots of
complicated logic to try to transparently handle ".exe" extensions.
We have ".exe" extensions because Windows 9x/Me requires it to execute
binaries. For the upcoming Cygwin 1.7 r
Larry Hall (Cygwin) wrote:
Here's a naive thought. See if it makes any sense. We have lots of
complicated logic to try to transparently handle ".exe" extensions.
We have ".exe" extensions because Windows 9x/Me requires it to execute
binaries. For the upcoming Cygwin 1.7 release (date TBD), we'
dle
> $(EXEEXT) all over the place, if they do it based on hostname rather than on
> what the default gcc output is. I would have to remove some of the .exe
> magic
> I've added in coreutils (but it would mean I'm closer to an upstream image).
Seems manageable but that&#
on
what the default gcc output is. I would have to remove some of the .exe magic
I've added in coreutils (but it would mean I'm closer to an upstream image).
>
> I realize this would be a hard break with the 1.5 Cygwin series since it
> would force all Cygwin packages
to see the truth - rather than creating "/foo",
the broken .exe magic in ln 6.7 created "/foo.exe", but then the auto-exe magic
in other commands (such as ls) means that 'ls foo' succeeds even if it had to
do 'ls foo.exe' under the hood.
>
> rm /foo
Here's a naive thought. See if it makes any sense. We have lots of
complicated logic to try to transparently handle ".exe" extensions.
We have ".exe" extensions because Windows 9x/Me requires it to execute
binaries. For the upcoming Cygwin 1.7 release (date TBD), we're dropping
support for Windo
On 4/9/07, Eric Blake wrote:
[ cut out lots of useful information to save space ]
Will your proposed changes in coreutils fix the following problem I
just discovered today?
Create a symbolic link
ln -s /usr/bin/foo /foo
where /usr/bin/foo is really usr/bin/foo.exe
ls -l /foo
returns
foo -> /us
ate dangling symlinks, and
then make them non-dangling later. The way I see it:
~ if invoking ln, require the source to exist (but possibly
with implicit .exe), and make the target end in .exe if the
source did (including via implicit .exe)
~ if invoking ln --disable-exe-magic, require the source
to
Eric Blake wrote:
> when creating symlinks, I plan to still auto-append the .exe to the link
> target if necessary (otherwise, exec*() succeeds but open() fails when
> dereferencing the symlink), but not to the link name.
That sounds correct. If open() fails on a link target that's missing an
.e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Revisiting an old thread...
According to Corinna Vinschen on 1/24/2007 7:38 AM:
> On Jan 24 06:45, Eric Blake wrote:
>> According to Corinna Vinschen on 1/24/2007 2:48 AM:
>>> This looks rather like a problem with the exe magic i
On Jan 24 06:45, Eric Blake wrote:
> According to Corinna Vinschen on 1/24/2007 2:48 AM:
> > This looks rather like a problem with the exe magic in coreutils. FWIW,
> > I never liked the idea to create "foo.exe.lnk" symlinks. They only slow
> > down the symlink pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 1/24/2007 2:48 AM:
>
> This looks rather like a problem with the exe magic in coreutils. FWIW,
> I never liked the idea to create "foo.exe.lnk" symlinks. They only slow
> down the symlin
gt; and it runs
>ln -s -f /usr/sbin/ssmtp /usr/sbin/sendmail
Thanks for the excellent diagnosis.
>
> My suggestion is that by default ln -s should not do any magic. If some magic
> is
> desired, users can define an alias or shell function that adds
> --enable-exe-magic
I
ult ln -s should not do any magic. If some
> > magic is
> > desired, users can define an alias or shell function that adds
> > --enable-exe-magic
> >
> > Pierre
>
> Probably just an oversight (in regards to symlinks) in the code handling .exe
> vs extention
mmands "sendmail" and "sendmail.exe" produce different results,
> cron keeps using exim and if exim is uninstalled then cron misbehaves.
>
> My suggestion is that by default ln -s should not do any magic. If some magic
> is
> desired, users can define an alias or sh
misbehaves.
My suggestion is that by default ln -s should not do any magic. If some magic is
desired, users can define an alias or shell function that adds
--enable-exe-magic
Pierre
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/p
Christopher Faylor wrote:
On Wed, Jul 20, 2005 at 04:04:54PM +0200, Krzysztof Duleba wrote:
But how does gprof know that foo doesn't exist? It has to open or stat it.
I thought that both open and stat calls support exe magic.
Sorry. That's not how it works. The only "ex
On Wed, Jul 20, 2005 at 04:04:54PM +0200, Krzysztof Duleba wrote:
>But how does gprof know that foo doesn't exist? It has to open or stat it.
>I thought that both open and stat calls support exe magic.
Sorry. That's not how it works. The only "exe magic" in the cygw
>
> But how does gprof know that foo doesn't exist? It has to open or stat it.
> I thought that both open and stat calls support exe magic.
stat() and exec*() support exe magic, open() does not. I don't know
exactly how gprof works, but it is probably doing an open() and f
Dave Korn wrote:
.exe magic doesn't work with gprof. Any ideas why?
And indeed, it doesn't work the other way round... [carrying on from your
testcase:]
[EMAIL PROTECTED] /artimi/firmware/test> mv foo.exe foo
[EMAIL PROTECTED] /artimi/firmware/test> rm gmon.out
[EMAIL PR
Original Message
>From: Krzysztof Duleba
>Sent: 20 July 2005 07:07
> .exe magic doesn't work with gprof. Any ideas why?
And indeed, it doesn't work the other way round... [carrying on from your
testcase:]
[EMAIL PROTECTED] /artimi/firmware/test> mv foo.ex
.exe magic doesn't work with gprof. Any ideas why?
$ cat foo.c
int main(){
}
$ gcc -pg -g foo.c -o foo.exe
$ ./foo
$ gprof foo
foo: No such file or directory
$ gprof foo.exe
Flat profile:
[...]
Regards
Krzysztof Duleba
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-s
96 matches
Mail list logo
