mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Rich Simoes wrote:
> I just feel that if the CMD/Bash window is launched by
> default instead of RXVT, then we as users need some
> configuration options so we can get a more useful or
> pleasing CMD/Bash window.

FWIW, I agree with you that the *default* configuration of the
native Woe32 console is just downright ugly.  It doesn't have to
be that way; here's how I set mine up in Win2K:--

1) Open the properties dialogue of the shortcut which starts
   the MSYS session, and add the `--norxvt' flag to the command
   line used to start the session, (for Win2K, it's in the field
   tagged as `Target:' on the `Shortcut' tab).

   If you are still using MSYS-1.0.10, you may need to update
   your MSYS.BAT file, to get support for the `--norxvt' flag;
   grab the latest version from CVS:
   http://mingw.cvs.sourceforge.net/mingw/msys/dvlpr/bin/msys.bat

   or rename MSYS' /bin/rxvt.exe to /bin/rxvt.no, to permanently,
   (but reversibly), disable it.

The remaining steps may also be completed in this same properties
dialogue window, but I've found it more reliable to apply and quit
the properties update, then start a session in the native console,
right-click on the window title bar, reopen the properties dialogue
from the context menu, and proceed from there; YMMV.

2) On the `Options' tab, select `Window' for the `Display options'
   property, and enable *both* `Quick Edit mode' and `Insert mode'
   for the `Edit options'.  Set the `Cursor size' property as you
   prefer it, (I set mine to `Small'), and leave the defaults for
   the `Command history' property.

3) On the `Font' tab, select a font and font-size with which you
   feel comfortable; on my 17in monitor at 1280x1024 resolution,
   I find `Lucida Console' at size 14 suits me.

4) On the `Layout' tab, adjust the `Window size' settings to get
   the window size to fill whatever area of the screen you like.
   I've set mine with a `Width' of 180 and a `Height' of 80, to
   make the window fill my entire screen; you may have to tweak
   these, to suit your own preference or screen resolution.

   After you've set your preferred `Window size', you should
   adjust the `Screen buffer size' properties, to establish the
   scroll buffer; I find that keeping `Screen buffer size.Width'
   the same as `Window size.Width' works best, and I have the
   `Height' for `Screen buffer size' set to 300, to give me 300
   lines of scrollable history.

   Set the `Window position' property to your own preference; I
   have mine with `Left' at -3, `Top' at -2, and I've disabled
   the `Let system position window' option.

5) On the `Colors' tab, activate the `Screen Background' property;
   select the leftmost slot in the colour pallette, and adjust the
   RGB fields of the `Selected Color Values' property, to achieve
   a background colour to your liking, (mine is RGB 255/255/192,
   which gives me a pale cream).  After making the final RGB field
   adjustment, left-click in another RGB field, *without* making
   any further change, otherwise your final change may not be
   committed.

   Activate the `Screen Text' property, select the second palette
   slot from the left, and select appropriate RGB values for the
   `Selected Color Values' property; this selection will relate to
   the text colour mapped to the `ESC[31m' SGR sequence.  Again,
   click in another RGB field, after the last adjustment.  Repeat,
   selecting each of the remaining palette slots from left to right.
   Ensure that the colour in the eighth slot from the left is how
   you want your normal text to appear; also, if you use `man' or
   `nroff', be aware that the fourth and sixth colours from the
   left will be substituted for underlined and heading (bold) text
   respectively.  Finally, select the eighth colour slot from the
   left, as the normal setting for the `Screen Text' property.

   Note: I haven't discovered the purpose of the `Popup Text' and
   `Popup Background' properties, but it does no harm to activate
   each of them, and select a suitable colour for each, from the
   palette you just defined for the `Screen Text' property; there
   is no need to adjust that palette any further--just select the
   colour slots you want to assign.

6) Select `Ok', and then the `Save properties for future windows
   with same title' option, `Ok' that, and you are done.

> I'll have to go back through the archives
> to find the previous discussions on the topics of Mouse
> or Keyboard Selection, Cut and Paste of text in the
> CMD/Bash window as none of those functions seem to work
> for me at this time.

It appears that you have not enabled the `Quick Edit mode' and
`Insert mode' options, as described in (2) above.  Do note that
the behaviour is not identical to RXVT's; you must:--

a) Drag the mouse, with left button depressed, to mark a selection.

b) Right click *once*, to copy the selection to the clipboard.

c) Right click *again*, to paste at the cursor in *any* console
   window, or use Ctrl-V to paste in any non-console window.

d) Repeat (c) as many times as you wish, for multiple copies of
   the same selection.

e) Repeat from (a), for a new selection.

HTH.  I'll try to find time to publish some of the info from this
thread on the Wiki, if no one beats me to it.

Regards,
Keith.

Keith MARSHALL wrote:
> ........
> That makes sense to me, but Earnie was always keen to promote RXVT; I
> agree that the more stable behaviour without RXVT is preferable.  What
> do other users think; should I make this change, for Cesar's upcoming
> MSYS-1.0.11 release?  Votes please!
> 
> Regards,
> Keith.

While I do prefer RXVT because I've used Xterms for years,
I do find that I must reluctantly use the CMD/Bash window
to test my interactive C programs. I've not done any builds
to date, but it is my understanding that some packages will
not build in the RXVT window which I feel is the most
compelling reason to consider making the CMD/Bash window
the default.

What I have to say about the CMD/Bash window probably
should  be in a thread of it's own. I'd be more inclined
to use  the CMD/Bash window by default if I could make it
"better".  By default, the CMD window with Bash that
gets launched looks a lot like the ugly Command Prompt
window launched from Windoze. I've recently begun playing
around with the desktop shortcut for MSYS and the msys.bat
file to get something that I find a bit more pleasing and
functional. I'll have to go back through the archives
to find the previous discussions on the topics of Mouse
or Keyboard Selection, Cut and Paste of text in the
CMD/Bash window as none of those functions seem to work
for me at this time.

I just feel that if the CMD/Bash window is launched by
default instead of RXVT, then we as users need some
configuration options so we can get a more useful or
pleasing CMD/Bash window.

Rich Simoes

Yin Xiofeng wrote:
> Hello, i have a problem described below.

This is the very problem for which I issued a call for votes
on a proposed solution, as recently as yesterday:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/22099
http://thread.gmane.org/gmane.comp.gnu.mingw.msys/3919

> $ cat test.c 
> #include <stdio.h>
> int main() {
> printf("I am alive! Beware.\n"); /* execute it first ?*/
> getchar(); /* or execute it first ?*/
> return 0;
> }

You are running your MSYS shell in RXVT, right?  And you see:
> $ gcc test.c 
> $ ./a.exe 
> --> must press 'Enter' button to continue...

*before* you see the `printf' output...

> I am alive! Beware.

giving you the impression that the `getchar()' is executed
before the `printf'?

In fact, the statements are executed in the correct order, as
you see when you invoke from cmd.exe.  Add an `fflush(stdout)'
after the `printf' statement, but before the `getchar()', and
you will see that this is so in MSYS too.  Your problem is the
broken stdout buffering in RXVT; the solution is to run your
MSYS shell *without* the encumbrance of RXVT.

Regards,
Keith.

On 2007-3-29 13:56 UTC, 殷晓峰 wrote:
> Hello, i have a problem described below.
[...]
> printf("I am alive! Beware.\n"); /* execute it first ?*/
> getchar(); /* or execute it first ?*/

Are you running this in MSYS with rxvt? If you are, then
try it without rxvt.

Here's part of a message posted a few hours ago in the
thread "Interactive mode in MSYS shell"; it describes an
RXVT problem that sounds like what you're reporting:

On 2007-3-29 10:30 UTC, Keith MARSHALL wrote:
| 1) Expected output is delayed in the block buffer, instead of
|    appearing on the screen; users are left waiting for prompts
|    that never appear on the screen, yet the application has
|    moved on, and is waiting for their input, (unless the
|    application has been sprinkled with `flush()' calls, to
|    explicitly work around this abnormal behaviour).

Hello, i have a problem described below.

$ cat test.c 
#include <stdio.h>
int main() {
        printf("I am alive! Beware.\n");         /* execute it first ?*/
        getchar();                                        /* or execute it first ?*/
        return 0;
}

$ gcc test.c 
$ ./a.exe 
<****must press 'Enter' button to continue execute ? execute getchar() first ? but printf was writed before getchar() ?
but execute it normal under xp 's cmd.exe
****>
I am alive! Beware.
$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Keith MARSHALL <kei...@to...> wrote:
>> How about in the next release of MSYS reversing the sense of the test,
>> in other words, you must supply --rxvt otherwise you get the stock
>> console.  It seems to be more headache than help at this point.
>>     
>
> That makes sense to me, but Earnie was always keen to promote RXVT; I
> agree that the more stable behaviour without RXVT is preferable.  What
> do other users think; should I make this change, for Cesar's upcoming
> MSYS-1.0.11 release?  Votes please!
>
> Regards,
> Keith.
>   
Yes, please make RXVT an option, instead of the default.

Keith MARSHALL wrote:
> 
> Whatever Cygwin may, or may not do, isn't really relevant.  It has an
> emulation layer, provided by cygwin1.dll, which furnishes the file
> system access functions.  Thus, it has the opportunity to deduce info
> about file attributes, and present that info in a format which matches
> the behaviour of a POSIX system.

Yes I agree.

> Unless you've built your cross-compiler as an MSYS application, i.e.
> you've linked it against msys-1.dll, there is no such emulation layer.
> I'm guessing that you have not built it this way, and that it is linked
> against MSVCRT; this would be the normal case.  Thus, the file system
> access functions call by your compiler and its associated tool chain
> will be the native `stat', `access', `chmod', etc., as furnished by
> MSVCRT; these have no comprehension of an `execute bit', and cannot
> report on whether or not a file is an executable -- there is no X_OK
> status for native `access' calls, and any attempt to set an execute
> bit with `chmod' is simply a no-op.
> 

Ah ok I understand. I was stuck in the MSYS view of the world.

> 
> Even if Win32 can successfully mount a foreign file system, e.g. via
> a Samba server running on the remote host, it will not understand the
> purpose of the `execute bit' assigned there; AFAIK it will simply ignore
> it, and still try to identify executables by their file name extensions.
>

I agree.

> And, in the case of a cross-compiler tool chain running natively on Win32,
> that will be the native `chmod', which will simply ignore the request to
> set an `executable bit'.

I agree.

> 
> Ok, I just installed autoconf 2.61 on my MSYS box, and then inspected the
> configure script generated from:
> 
>   AC_INIT
>   AC_PROG_CC
>   AC_LINK_IFELSE([[int main(){return 0;}]],[echo ok],[echo oops!])
>   AC_OUTPUT
> 
> What I see, for the AC_LINK_IFELSE test, after the link attempt is:
> 
>   * a sequence of checks on the exit status of the link command
>   * a test to confirm that conftest$ac_exeext exists, and is not
>     an empty file
>   * a test, formulated as $as_test_x conftest$ac_exeext, to check
>     that the resultant linker output file is executable
> 
> Now, if I add an echo $as_test_x, I see it is defined as `test -x'.  Thus,
> your problem seems to be that `test -x' in MSYS sh.exe fails for your 
> output file;

This is correct.

> that probably is correct behaviour, from the MSYS perspective, since
> it cannot hope to execute that file.  What you really need, is to have
> $as_test_x defined as the more general `test -f', (although, the earlier
> `test -s' makes this redundant, and the `$as_test_x' stuff doesn't seem to
> be present in autoconf-2.60 or earlier), when you are running 
> AC_LINK_IFELSE
> tests with your cross-compiler, hosted on Win32 and running under MSYS;
> whether that is true for the more general cross-compiling case is an issue
> which I think the autoconf maintainers should be invited to comment on.
> You might like to start a thread on aut...@gn...

I will now I have the MinGW (MSYS) point of view.

> As a final thought, for a Q&D workaround for this, you could create a
> config.site file with `as_test_x="test -f"' as content, (or add this to
> an existing config.site, if you use one).  That seems to override the
> `test -x' with a `test -f', so restoring the old behaviour WRT this
> AC_LINK_IFELSE test.

I will look into this as a work around. It will keep my moving with the RTEMS 
tools.

Regards
Chris

Chris Johns wrote, quoting me:
>>> Does MSYS support the setting of the execute bit ?
>> 
>> No, not AFAIK.  There is no such bit defined for the attribute field 
>> within the directory structure on either the underlying NTFS or FAT32 
>> file system.  How can MSYS set an entity which doesn't exist?
>
> An RTEMS user reported cygwin does support it on NTFS:
>
> http://www.rtems.org/ml/rtems-users/2007/march/msg00109.html
>
> NTFS as a solution does mean FAT32 users need to change formats which
> may not be practical.

Whatever Cygwin may, or may not do, isn't really relevant.  It has an
emulation layer, provided by cygwin1.dll, which furnishes the file
system access functions.  Thus, it has the opportunity to deduce info
about file attributes, and present that info in a format which matches
the behaviour of a POSIX system.

Unless you've built your cross-compiler as an MSYS application, i.e.
you've linked it against msys-1.dll, there is no such emulation layer.
I'm guessing that you have not built it this way, and that it is linked
against MSVCRT; this would be the normal case.  Thus, the file system
access functions call by your compiler and its associated tool chain
will be the native `stat', `access', `chmod', etc., as furnished by
MSVCRT; these have no comprehension of an `execute bit', and cannot
report on whether or not a file is an executable -- there is no X_OK
status for native `access' calls, and any attempt to set an execute
bit with `chmod' is simply a no-op.

> A possible reason given in the bug for RTEMS:
>
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1228
>
> is mounting of cross-compiler built executables. It might not be
> applicable to MinGW or Windows but is a valid case. Embedded Linux
> for say an ARM or Coldfire processor with build tools on a IA32 Linux
> host and NFS mounted by the embedded target.

Even if Win32 can successfully mount a foreign file system, e.g. via
a Samba server running on the remote host, it will not understand the
purpose of the `execute bit' assigned there; AFAIK it will simply ignore
it, and still try to identify executables by their file name extensions.

> The code in binutils for bfd is 'bfd_close' and it states it will call
> chmod if the file is open for writing and marked as an executable. This
> would be the same for native and cross-compilation.

And, in the case of a cross-compiler tool chain running natively on Win32,
that will be the native `chmod', which will simply ignore the request to
set an `executable bit'.

>> It should be sufficient for AC_LINK_IFELSE to verify that the linker
>> can be sucessfully invoked to create an output file, without requiring
>> it to be executable on the build platform; that surely must break 
>> cross-compilation in general, for in the normal case, the files created 

>> by the linker are not executable on the build platform.
>
> Sure they are not suitable for execution but they may be runable. For
> example Linux will try and run an RTEMS executable build for a pc586
> target. It just seg faults and terminates.

You can achieve a similar effect on Win32, by renaming a file to have a
`.exe' extension; the OS will believe it to be executable, but it will
either hang or crash, if you then try to run it.

> The linker defaults to 'a.out' for all executables formats. This default
> can be modified for special output formats. The pe format used on 
Windows
> is such a format and here the default output filename is changed to 
'a.exe'.
> This means a native compiler on Windows with no command line specified 
will
> output a file with the name 'a.exe'. Autoconf checks the default output
> filename for a .exe extension and remembers it by setting
>
>   $ac_exeext = '.exe'
>
> It is then used in the AC_LINK_IFELSE macro so the output file names 
have
> the .exe extension and have the execute bit set. The 'a.out' default 
output
> file name sets $ac_exeext = ''.

But surely, before you ever get to the stage of an AC_LINK_IFELSE test, 
you
should have invoked AC_PROG_CC, to test your *cross-compiler*; that would
have set $ac_exeext to nothing, so AC_LINK_IFELSE has no business checking
for $ac_exeext == .exe to signify an executable, and, since the build host
doesn't support any concept of an `execute bit', it has no business 
looking
for that either; the best that it can hope for is that the linker produces
an output file, which is *potentially* an executable, for there is no way
it can actually confirm that for sure, unless there is some `magic' number
in the file, which AC_LINK_IFELSE can somehow be taught to recognise.

Ok, I just installed autoconf 2.61 on my MSYS box, and then inspected the
configure script generated from:

  AC_INIT
  AC_PROG_CC
  AC_LINK_IFELSE([[int main(){return 0;}]],[echo ok],[echo oops!])
  AC_OUTPUT

What I see, for the AC_LINK_IFELSE test, after the link attempt is:

  * a sequence of checks on the exit status of the link command
  * a test to confirm that conftest$ac_exeext exists, and is not
    an empty file
  * a test, formulated as $as_test_x conftest$ac_exeext, to check
    that the resultant linker output file is executable

Now, if I add an echo $as_test_x, I see it is defined as `test -x'.  Thus,
your problem seems to be that `test -x' in MSYS sh.exe fails for your 
output
file; that probably is correct behaviour, from the MSYS perspective, since
it cannot hope to execute that file.  What you really need, is to have
$as_test_x defined as the more general `test -f', (although, the earlier
`test -s' makes this redundant, and the `$as_test_x' stuff doesn't seem to
be present in autoconf-2.60 or earlier), when you are running 
AC_LINK_IFELSE
tests with your cross-compiler, hosted on Win32 and running under MSYS;
whether that is true for the more general cross-compiling case is an issue
which I think the autoconf maintainers should be invited to comment on.
You might like to start a thread on aut...@gn...

As a final thought, for a Q&D workaround for this, you could create a
config.site file with `as_test_x="test -f"' as content, (or add this to
an existing config.site, if you use one).  That seems to override the
`test -x' with a `test -f', so restoring the old behaviour WRT this
AC_LINK_IFELSE test.

Regards,
Keith.

Keith Marshall wrote:
> [Topic relocated from MinGW-dvlpr; it isn't relevant there]

Yeap I agree. Thanks for moving it.

> 
> On Tuesday 27 March 2007 09:01, Chris Johns wrote:
>> I am seeing an issue with the AC_LINK_IFELSE test in autoconf-2.61. A
>> change in autoconf:
>>
>> http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/general.m4?
>> root=autoconf&r1=1.931&r2=1.932
>>
>> has added an execute bit test on the linker output. The RTEMS
>> cross-compilers (ftp://www.rtems.org/pub/rtems/windows/) fail to pass
>> this test on an Windows XP. The MinGW RTEMS tools contain
>> autoconf-2.61 as RTEMS requires it.
> 
> Well, I consider that to be a bug in autoconf-2.61.
> 

It could be but it may be in the way $ac_exeext is handled rather than the
execute bit test that has been added. The execute bit works for the native
MinGW compiler which defaults to the 'a.exe' output file name. It is just
cross-compilers that do not work.

>> The AC_LINK_IFELSE uses $ac_exeext and for RTEMS this is "". The
>> RTEMS cross-compiler default output filename is 'a.out' so the
>> autoconf test that sets $ac_exeext takes a.out to have no executable
>> extension.
>>
>> Does MSYS support the setting of the execute bit ?
> 
> No, not AFAIK.  There is no such bit defined for the attribute field 
> within the directory structure on either the underlying NTFS or FAT32 
> file system.  How can MSYS set an entity which doesn't exist?

An RTEMS user reported cygwin does support it on NTFS:

http://www.rtems.org/ml/rtems-users/2007/march/msg00109.html

NTFS as a solution does mean FAT32 users need to change formats which may not
be practical.

> 
>> What sets the executable bit in MSYS ?
> 
> AFAIK, nothing.  See above.
> 
>> An RTEMS user has posted that NTFS works with Cygwin and FAT32 did
>> not.
> 
> Cygwin emulates POSIX, on top of Win32.  I don't know how it emulates 
> the execute bits of the POSIX file system directory entries.
> 
> On native Win32, a file is considered executable if it has a qualifying 
> file name extension.  MSYS uses this feature, but extends it to also 
> treat scripts as executable, if they are adorned by a shebang.  I don't 
> know if it also considers any other `magic' present within the file, as 
> an indicator that it is an executable, but it does not use an `execute 
> bit', for there simply isn't one.

Yes the execute bit is just a list of extensions plus the magic 3 byte test
for scripts. This does not help in the case of the AC_LINK_IFELSE test and a
cross-compiler. Here autoconf specifies the output file name and $ac_exeext is
"". I do not like the idea of adding 'conftest' to the list of tests. If
$ac_exeext = '.exe' things would work. See below for the autoconf test to
handle $ac_exeext.

> In any case, you are using a cross compiler, so the linker output is not 
> an executable on the Win32 host; why should it be flagged as such?

A possible reason given in the bug for RTEMS:

https://www.rtems.org/bugzilla/show_bug.cgi?id=1228

is mounting of cross-compiler built executables. It might not be applicable to
MinGW or Windows but is a valid case. Embedded Linux for say an ARM or
Coldfire processor with build tools on a IA32 Linux host and NFS mounted by
the embedded target.

>  It 
> should be sufficient for AC_LINK_IFELSE to verify that the linker can 
> be sucessfully invoked to create an output file, without requiring it 
> to be executable on the build platform;

Not for this user of autoconf:

http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00068.html

The code in binutils for bfd is 'bfd_close' and it states it will call chmod
if the file is open for writing and marked as an executable. This would be the
same for native and cross-compilation.

> that surely must break 
> cross-compilation in general, for in the normal case, the files created 
> by the linker are not executable on the build platform.

Sure they are not suitable for execution but they may be runable. For example
Linux will try and run an RTEMS executable build for a pc586 target. It just
seg faults and terminates.

The linker defaults to 'a.out' for all executables formats. This default can
be modified for special output formats. The pe format used on Windows is such
a format and here the default output filename is changed to 'a.exe'. This
means a native compiler on Windows with no command line specified will output
a file with the name 'a.exe'. Autoconf checks the default output filename for
a .exe extension and remembers it by setting $ac_exeext = '.exe'. It is then
used in the AC_LINK_IFELSE macro so the output file names have the .exe
extension and have the execute bit set. The 'a.out' default output file name
sets $ac_exeext = ''.

> The behaviour you report is so anomalous, that can only be considered to 
> be an autoconf bug.  I suggest you follow it through, by reporting it 
> to bug...@gn...

I will if this is considered the result of this discussion.

> Regards,
> Keith.
> 
> FWIW, I've built autoconf-2.61 on my MSYS host, but have not deployed 
> it.  It fails one test, in its own test suite, where autoconf-2.60 
> passes on all counts.  I shall be posting my own bug report.

Oh. Could you please send the PR details when it is raised. I cross compile
everything so running tests is missed out.

Regards
Chris

On 2007-3-28 9:34 UTC, Keith MARSHALL wrote:
> 
> Votes please!

Yes. Favor stability. By default, don't use rxvt.

[I'm cross posting to MinGW-MSYS, as this seems more applicable to users
 of that list, and I want their opinions.  Nevertheless, I still value
 the opinions of the MinGW-users community.  If you receive two copies
 because you subscribe to both lists, please accept my apologies; (I'll
 only count your vote once though, if it's obvious that you've replied
 more than once :-) )]

Brian Dessent wrote, quoting me:
>> I considered this, a few months ago.  I could never get the development
>> versions of console-2 to run on my Win2K box -- needed DLLs which are
>> not present as part of the core OS.  The released version runs, but I
>> don't really see any advantage over the standard Win32 console.
>
> One of the main advantages to me is that the stock console only lets you
> use a small number of fonts (a handful of fixed point sizes and Lucida
> Console) whereas the Console-2 app lets you pick any installed font,
> fixed or TrueType, in any size.  And the tabbed interface, etc...

Yeah, fonts are limited in standard Win32 console.  I don't see that as a
problem.  Lucida Console seems quite acceptable to me as a console font; I
don't need anything more, but clearly that's a personal choice.

Tabbed interface?  I don't see it in console-1.5; I haven't tried again
recently, but when I did, I couldn't get console-2 to run.  Shame, because
that's an advantage I would appreciate.

>> I use MSYS daily, since v1.0.8, and I've not used RXVT *ever*; (it's
>> just too flaky for my needs).  Just delete rxvt.exe from your MSYS /bin
>> directory, or start with the --norxvt switch for v1.0.11, and it will
>> start in a standard Win32 console.
>
> How about in the next release of MSYS reversing the sense of the test,
> in other words, you must supply --rxvt otherwise you get the stock
> console.  It seems to be more headache than help at this point.

That makes sense to me, but Earnie was always keen to promote RXVT; I
agree that the more stable behaviour without RXVT is preferable.  What
do other users think; should I make this change, for Cesar's upcoming
MSYS-1.0.11 release?  Votes please!

Regards,
Keith.

[Topic relocated from MinGW-dvlpr; it isn't relevant there]

On Tuesday 27 March 2007 09:01, Chris Johns wrote:
> I am seeing an issue with the AC_LINK_IFELSE test in autoconf-2.61. A
> change in autoconf:
>
> http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/general.m4?
>root=autoconf&r1=1.931&r2=1.932
>
> has added an execute bit test on the linker output. The RTEMS
> cross-compilers (ftp://www.rtems.org/pub/rtems/windows/) fail to pass
> this test on an Windows XP. The MinGW RTEMS tools contain
> autoconf-2.61 as RTEMS requires it.

Well, I consider that to be a bug in autoconf-2.61.

> The AC_LINK_IFELSE uses $ac_exeext and for RTEMS this is "". The
> RTEMS cross-compiler default output filename is 'a.out' so the
> autoconf test that sets $ac_exeext takes a.out to have no executable
> extension.
>
> Does MSYS support the setting of the execute bit ?

No, not AFAIK.  There is no such bit defined for the attribute field 
within the directory structure on either the underlying NTFS or FAT32 
file system.  How can MSYS set an entity which doesn't exist?

> What sets the executable bit in MSYS ?

AFAIK, nothing.  See above.

> An RTEMS user has posted that NTFS works with Cygwin and FAT32 did
> not.

Cygwin emulates POSIX, on top of Win32.  I don't know how it emulates 
the execute bits of the POSIX file system directory entries.

On native Win32, a file is considered executable if it has a qualifying 
file name extension.  MSYS uses this feature, but extends it to also 
treat scripts as executable, if they are adorned by a shebang.  I don't 
know if it also considers any other `magic' present within the file, as 
an indicator that it is an executable, but it does not use an `execute 
bit', for there simply isn't one.

In any case, you are using a cross compiler, so the linker output is not 
an executable on the Win32 host; why should it be flagged as such?  It 
should be sufficient for AC_LINK_IFELSE to verify that the linker can 
be sucessfully invoked to create an output file, without requiring it 
to be executable on the build platform; that surely must break 
cross-compilation in general, for in the normal case, the files created 
by the linker are not executable on the build platform.

The behaviour you report is so anomalous, that can only be considered to 
be an autoconf bug.  I suggest you follow it through, by reporting it 
to bug...@gn...

Regards,
Keith.

FWIW, I've built autoconf-2.61 on my MSYS host, but have not deployed 
it.  It fails one test, in its own test suite, where autoconf-2.60 
passes on all counts.  I shall be posting my own bug report.

Cesar Strauss wrote:
> Julien Lecomte wrote:
>> There's a problem with 'rm -fr' when using a full qualified windows 
>> translated path and reparse points.
>> (...)
>>
> 
> I am interested in testing this bug, but I do not know how to create a 
> reparse point. The junction command from sysinternals didn't work for 
> me. I am using Windows XP Home Edition.

I use a shell extension called NTFSLink to create the links. I'm 
probably not using the last version of it, but it can be found here:
http://www.elsdoerfer.info/=ntfslink

The bug is reproducible since I use the same version of tools on both my 
home and work computer and have the same behavior on both.

> I did manage to create a junction to the root of my f: drive by using 
> the Disk Manager. I did not try rm -rf because I didn't wanted to risk 
> losing the contents of that drive.

Yes, do be careful because reparse points are symbolic links with less 
flavor and more danger ;-)

> Do ls also fails for you?  

ls works for me, in both cases of a drive or a folder reparse point.

$ ls --version
ls (GNU coreutils) 5.97

Julien

Julien Lecomte wrote:
> There's a problem with 'rm -fr' when using a full qualified windows 
> translated path and reparse points.
> 
> For example:
> $ cd /d/devroot
> $ mkdir test
> $ rm -fr test
> rm: cannot remove directory `test': No such file or directory
> $ cd /devroot
> $ rm -fr test
> -> OK
> $ cd /d/mSys/devroot
> $ mkdir test
> $ rm -fr test
> -> OK
> 
> Current versions:
> msys-1.0.dll: 1000.11.0.0, 2007-01-12 12:05 (from 
> msysCORE-1.0.11-2007.01.19-1.tar.bz2 not recompiled from source)
> 
> $ rm --version
> rm (GNU coreutils) 5.97
> (from coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2)
> 
> System information:
> MSYS  installed in 'D:\mSys'
> Devroot is a reparse point from "D:\mSys\devroot" to "D:\devroot" (note: 
> reparse point, not a fstab entry!)
> 
> $ echo $PATH
> /home/bin:/mingw/bin:/bin:/c/Program Files/Command
> 
> $ type -a rm
> rm is /bin/rm
> rm is /c/Program Files/Command/rm
> 
> $ echo $MSYSTEM
> MINGW32
> 
> Julien
> 
> 

Hi, Julien

I am interested in testing this bug, but I do not know how to create a 
reparse point. The junction command from sysinternals didn't work for 
me. I am using Windows XP Home Edition.

I did manage to create a junction to the root of my f: drive by using 
the Disk Manager. I did not try rm -rf because I didn't wanted to risk 
losing the contents of that drive.

In cmd.exe:
C:\temp\junction> dir
(...)
25/03/2007  19:53    <DIR>          .
25/03/2007  19:53    <DIR>          ..
25/03/2007  19:53    <JUNCTION>     drive_f
25/03/2007  11:48    <DIR>          test1
25/03/2007  11:48    <DIR>          test2
(...)

Do ls also fails for you?  For me, it gives:

cstrauss@CESAR /c/temp/junction
$ ls
ls: drive_f: No such file or directory
test1/  test2/

Cesar

There's a problem with 'rm -fr' when using a full qualified windows 
translated path and reparse points.

For example:
$ cd /d/devroot
$ mkdir test
$ rm -fr test
rm: cannot remove directory `test': No such file or directory
$ cd /devroot
$ rm -fr test
-> OK
$ cd /d/mSys/devroot
$ mkdir test
$ rm -fr test
-> OK

Current versions:
msys-1.0.dll: 1000.11.0.0, 2007-01-12 12:05 (from 
msysCORE-1.0.11-2007.01.19-1.tar.bz2 not recompiled from source)

$ rm --version
rm (GNU coreutils) 5.97
(from coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2)

System information:
MSYS  installed in 'D:\mSys'
Devroot is a reparse point from "D:\mSys\devroot" to "D:\devroot" (note: 
reparse point, not a fstab entry!)

$ echo $PATH
/home/bin:/mingw/bin:/bin:/c/Program Files/Command

$ type -a rm
rm is /bin/rm
rm is /c/Program Files/Command/rm

$ echo $MSYSTEM
MINGW32

Julien

On Friday 16 March 2007 09:11, MinGW MSYS Discussion List wrote:
> Basically I want to know if the portmaker maintainers are interested
> in receiving patches

Patches are always welcome :-)

However, you may wish to reconsider whether this particular effort will 
be worthwhile, in view of Greg Chicares' response, (which offers a well 
balanced perspective, and with which I completely agree).

Working around the problem you percieve in portmaker may create only a 
tiny chip in the tip of the iceberg; avoiding spaces in path names in 
the first place seems the more favourable solution.

Regards,
Keith.

> try -z3 instead of -z9

This may work, but it would be nice to get the new version of cvs
working correctly considering  the previous version of cvs handled -z9
correctly.

Cheers!

Chris

-- 
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org

try -z3 instead of -z9

On 3/17/07, Chris Sutcliffe <ir0...@gm...> wrote:
> I just got a chance to test out this updated version of cvs with MSYS,
> and I keep getting the following error when the cvs update has
> completed:
>
> Hm, dispatch protocol error: type 80 plen 26
>
> I have 'cvs -z9' (minus the quotes) in my .cvsrc and I am executing a
> 'cvs up' from the sourceware repository.
>
> Any ideas as to what the cause could be?
>
> Chris
>
> --
> Chris Sutcliffe
> http://ir0nh34d.googlepages.com
> http://ir0nh34d.blogspot.com
> http://emergedesktop.org
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

I just got a chance to test out this updated version of cvs with MSYS,
and I keep getting the following error when the cvs update has
completed:

Hm, dispatch protocol error: type 80 plen 26

I have 'cvs -z9' (minus the quotes) in my .cvsrc and I am executing a
'cvs up' from the sourceware repository.

Any ideas as to what the cause could be?

Chris

-- 
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org

[Mail from "MinGW MSYS Discussion List" might be mistaken
for a message from the mailing-list software or an official
announcement; please consider changing your alias.]

On 2007-3-16 9:11 UTC, MinGW MSYS Discussion List wrote:
> 
> My Windows username is my real first, middle and lastname, including
> spaces. That proved to be a big problem for portmaker (and for
> configure-scripts, and for makefiles).
> 
> I tried to fix the problem in portmaker by changing a lot of $1 into
> "$1", but that only exposed the same problem with configure/makefile.

Like many *nix tools, 'make' uses the space character as a
delimiter, but ms windows encourages spaces in pathnames.
Quoting may work around some of the conflicts, but not all.
The 'make' mailing list archives, accessible here:
  http://savannah.gnu.org/mail/?group=make
contain much discussion of this conflict.

> For now I resorted to set HOME in msys.bat and point it to a directory
> with no spaces in the name.

That's generally the best solution. Another way is to use "8.3"
filenames like "DOCUME~1\ADMINI~1", but hardcoding those is
dangerous and generating them on the fly seems laborious. Maybe
filesystem mounts would be yet another solution.

> I don't want to save the world in one go, so I will forget about the
> problem that the auto-tools has with spaces in directory names and
> concentrate on portmaker.

You've got scripts that use autotools, which use 'make', and
you're thinking of changing the scripts to quote parameters,
right? But will it be feasible to change the downstream tools
so that they do the right thing with those quoted parameters?
I'd consider that before embarking on this course. AFAIK,
others have looked at those downstream problems and concluded
that solving them isn't worth the cost when your "HOME" idea
above sidesteps the issues neatly.

I have been experimenting with portmaker for some time now, and have run
into a few problems. Most of them concern the lack of quoting around
variables and parameters.

My Windows username is my real first, middle and lastname, including spaces.
That proved to be a big problem for portmaker (and for configure-scripts,
and for makefiles).

I tried to fix the problem in portmaker by changing a lot of $1 into "$1",
but that only exposed the same problem with configure/makefile.

For now I resorted to set HOME in msys.bat and point it to a directory with
no spaces in the name.

I don't want to save the world in one go, so I will forget about the problem
that the auto-tools has with spaces in directory names and concentrate on
portmaker.

Basically I want to know if the portmaker maintainers are interested in
receiving patches for this problem, before I start to go through the scripts
and add d-quotes a lot of places.

-- 
Jan

WRT correct use of the name `MSYS', vs. the incorrect `MinSYS',
Liam Gadabout (or some such name which doesn't quite match what
I expect humans to be called) wrote:

> Seriously though, enough of this emotional "pissing around" - if you
> want to reject something that happens to be more logical for no reason
> other than some perverted sense of admiration and loyalty - go get a
> life... I am terminating my involvement in this particular thread.
> Over and out.

Always the last resort of he who tries to defend the indefensible,
yet still insists on having the last word; if he's convinced me of
anything, it's that he's an arrogant prat.

And that is positively *my* final word on the subject.  This list
supports MSYS, not some mythical product called MinSYS; if you want
support for that, look to the MinSYS list, wherever that might be.

Regards,
Keith.

> > I will neither bastardise nor denigrate
> > that choice of name, just because you consider it an anomaly;
>
> Yes yes - getting rather emotional aren't we? Otherwise, you wold stop
> contradicting yourself - if you say that it is "just me" who considers
> MinSYS to be more logical, then why would you write (in a previous
> post of yours):
> "I'm wondering why it is that so many people insist on calling MSYS `MinSYS'?"
> If there are "so many people" who would rather call it MinSYS, then it
> could not possibly be just me...

To clarify a little further, my objection to your post is that the phrase

"just because you consider it an anomaly"

had conveniently left out an earlier statement of yours which
mentioned that there are "so many people" who insist on calling MSYS
the same way that I did/do - MinSYS.

Consequently, your argument was being presented in contradiction to
the context set out by your earlier posts: as if the MinSYS calling
practice is somehow a point of conflict just because I consider it to
be a more logical option and not due to the fact that it happens to be
the preference of so many others as well.

I am pointing out this fact together with illustrating the subsequent
bias and lack of objectivity in your "arguments". To avoid this, you
should have stated:

> I will neither bastardise nor denigrate
> that choice of name, just because you [AND SO MANY OTHERS] consider it an anomaly;

to which the only available response is "ya voll' furer".

Seriously though, enough of this emotional "pissing around" - if you
want to reject something that happens to be more logical for no reason
other than some perverted sense of admiration and loyalty - go get a
life... I am terminating my involvement in this particular thread.
Over and out.

On 3/13/07, Keith MARSHALL <kei...@to...> wrote:
> It was not I who coined the name `MSYS', but I respect the wishes of
> the gentleman who did, (I believe it was Earnie, and that respect is
> redoubled on account of the huge effort he has almost singlehandedly
> put into its development).  I will neither bastardise nor denigrate
> that choice of name, just because you consider it an anomaly; `MSYS'
> it is, and `MSYS' it will remain; I consider it an insult to the
> original developer, to carelessly call it `MinSYS'.

Respect and admiration is one thing, not recognizing consistency or
just not listening to plain reason is another - don't confuse the two.
I also have a lot of admiration for MinGW/MinSYS developers, but that
does not mean that one should not evaluate things form
logical/unemotional point of view and therefore be able to disagree
with certain things (naming convention notwithstanding)... and if
there was a good reason to call it MSYS (e.g. at a time of MSYS being
coined, the MinSYS was already taken, etc.) then such should have been
presented without getting on this pathos-filled "respect" hysteria.

For example I could also have stated, in response to your comments
about Ffmpeg using bash, that prerequisite for "bash" in Ffmpeg
configure scripts is something that I happen to respect as "wishes of
their developers" and it is out of that "respect" that I would
consider any suggestion of a bug as an insult" ... but I did not state
this ... because anyone who takes a logical
argument/suggestions-of-a-bug and considers it to be an insult - is
simply retarded.

> I will neither bastardise nor denigrate
> that choice of name, just because you consider it an anomaly;

Yes yes - getting rather emotional aren't we? Otherwise, you wold stop
contradicting yourself - if you say that it is "just me" who considers
MinSYS to be more logical, then why would you write (in a previous
post of yours):
"I'm wondering why it is that so many people insist on calling MSYS `MinSYS'?"
If there are "so many people" who would rather call it MinSYS, then it
could not possibly be just me...


> Your wording was sufficiently ambiguous, leading to the impression that
> you may have thought that it was...

then you should have asked for clarification from me re. ambiguity in
question and your subsequent impression - instead of making incorrect
assumptions and then acting upon them.

> There was no intent, on my part, to patronise;

intent != result

Howard Chu wrote:
> I just noticed [...] bash is never using buffered I/O; it's
> reading script files one character at a time. This behavior is
> totally unnecessary.
>
> This patch fixes the behavior:
<patch>
Index: input.c
===================================================================
RCS file: /cvsroot/mingw/msys/packages/bash/3.1/input.c,v
retrieving revision 1.2
diff -u -r1.2 input.c
--- input.c     11 Aug 2006 17:21:39 -0000      1.2
+++ input.c     13 Mar 2007 02:00:16 -0000
@@ -337,7 +337,7 @@
  #if ! (__CYGWIN__ || __MSYS__)
  #  define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) >= 0)
  #else
-#  define fd_is_seekable(fd) 0
+#  define fd_is_seekable(fd) 1
  #endif /* __CYGWIN__ */

  /* Take FD, a file descriptor, and create and return a buffered stream
</patch>

Thanks for the patch, Howard.

This may have been better directed to the MinGW-dvlpr list, or
even better still, the patch tracker, but no matter.  I'll leave
it to Cesar to approve; subject to that, you may commit it.

Regards,
Keith.