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

On Monday 25 June 2007 15:16, Yi Yi wrote:
> By the way. The gcc of my MSYS is 4.2.0 and the make is 3.8.1. Both
> of them were compiled from the latest source(compiled by GCC 3.4.5).

This may well be the cause of your problem. =A0If you've built make-3.81
yourself, it is most likely a native build, and not the special build we
provide for MSYS, which is currently make-3.79.  Native builds of make=20
tend to not work too well in the MSYS environment.  Furthermore, since=20
you are using a pre-1.0.11 version of MSYS, you MUST NOT put your=20
native build of make in the /bin directory; this is documented in the=20
README file you read when you installed MSYS -- you DID read it, didn't=20
you?  The error you have reported is symptomatic of you having=20
committed this very blunder.

Can you build libiconv-1.11 using the official tools we provide? =A0We've
kept them at versions we know to be stable; if you want to experiment
with your own builds, at unsupported versions, then I'm afraid you will
have to be prepared to debug the entire build system for yourself too.

Also, did you note my warning about the wchar_t bug in stock
libiconv-1.11? =A0If that's important to you, you need the patch in our
mingwPORT.

Regards,
Keith.

On 6/26/07, David Kastrup <da...@gn...> wrote:
> "Daniel C. Bastos" <db...@to...>
> writes:
>
> > I currently keep my .emacs in c:\ and in ~/ in msys. I tried putting it
> > in c:\emacs and in c:\emacs\bin, but emacs seems to ignore them there.
> >
> > The manual says
> >
> > The Init File, `~/.emacs'
> > =========================
> >
> >   When Emacs is started, it normally loads a Lisp program from the file
> > `.emacs' or `.emacs.el' in your home directory.  We call this file your
> > "init file" because it specifies how to initialize Emacs for you.  You
> > can use the command line switch `-q' to prevent loading your init file,
> > and `-u' (or `--user') to specify a different user's init file (*note
> > Entering Emacs::).
> >
> > But I couldn't get -u or --user to work. I tried
> >
> > %emacs -u /c/emacs/.emacs
> > %emacs --user /c/emacs/.emacs
> > %emacs -u 'c:\emacs\.emacs'
> > %emacs --user 'c:\emacs\.emacs'
>
> Do you actually have a user called /c/emacs/.emacs?  I find that
> unlikely.

I just noticed the proper usage of --user by looking at `emacs --help`,
but I couldn't tell that by the text in the info page (above). It
mentions a ``user's init file'' so I thought of giving it a path to a
user's init file, however strange the flag --user would've been for
that.

> > If I can get this flag to work, then my problem is solved. What I
> > currently do is use a script that copies the .emacs from /c/ to ~/
> > before it loads emacs from the shell. But how do you guys keep your
> > .emacs in one place?
> >
> > I need it in both places because emacs reads c:\.emacs when I call
> > it from a Windows hotkey, and it reads ~/.emacs when called from
> > msys.
>
> How about actually setting the HOME variable in your system?

That worked a few days ago after someone suggesting the same.

"Daniel C. Bastos" <db...@to...>
writes:

> I currently keep my .emacs in c:\ and in ~/ in msys. I tried putting it
> in c:\emacs and in c:\emacs\bin, but emacs seems to ignore them there.
>
> The manual says
>
> The Init File, `~/.emacs'
> =========================
>
>   When Emacs is started, it normally loads a Lisp program from the file
> `.emacs' or `.emacs.el' in your home directory.  We call this file your
> "init file" because it specifies how to initialize Emacs for you.  You
> can use the command line switch `-q' to prevent loading your init file,
> and `-u' (or `--user') to specify a different user's init file (*note
> Entering Emacs::).
>
> But I couldn't get -u or --user to work. I tried
>
> %emacs -u /c/emacs/.emacs
> %emacs --user /c/emacs/.emacs
> %emacs -u 'c:\emacs\.emacs'
> %emacs --user 'c:\emacs\.emacs'

Do you actually have a user called /c/emacs/.emacs?  I find that
unlikely.

> If I can get this flag to work, then my problem is solved. What I
> currently do is use a script that copies the .emacs from /c/ to ~/
> before it loads emacs from the shell. But how do you guys keep your
> .emacs in one place?
>
> I need it in both places because emacs reads c:\.emacs when I call
> it from a Windows hotkey, and it reads ~/.emacs when called from
> msys.

How about actually setting the HOME variable in your system?


-- 
David Kastrup

Hi, Thanks for you help.

> As a workaround for now, perhaps can you can try entering in the proper
> directory (where make was) and run the command above without the outer
> quotes; if it compiles the file, then you run make again and since the
> file is already compiled, make will try the next step in the compilation
> procedure.

I just get into the sub-directory of ../libcharset/lib and retried as
what you guys told me to. Actually, there is something wrong with the
command

gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
"-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
-DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
-DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
-Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c" -o
localcharset.o

On the first try,  I only deleted the outer quotes. The make command
still failed. It turned out that the path of DLIBDIR was also
incorrect. (Why is there a "\\" in it ?). So I changed "\\" into "\"",
deleted the outer quotes and tried for the second time. There, it
worked. The localcharset.o was generated. Is it possible that there
are some bugs of makefile in the libiconv-1.11 package ?

However, when I get back the root directory of libiconv and executed
make again, the same error occurred AGAIN. And I noticed that the
localcharset.o generrated a second ago disappered all of a sudden. It
seemed that the Makefile ignored the existing localcharset.o and
retried compiling it again.(Well , actually, in the makefile of the
lib directory, the object is localcharset.lo, not localcharset.o).

> GNU libiconv-1.11 builds OOTB, for me using either MSYS-1.0.10, or the
> candidate MSYS-1.0.11.  MSYS-1.0.9 is ancient; I recommend upgrading.

I will update my MSYS and try compiling it under the new MSYS. I hope
it can worked.

By the way. The gcc of my MSYS is 4.2.0 and the make is 3.8.1. Both of
them were compiled from the latest source(compiled by GCC 3.4.5).

> > Hi, everybody .
>
> Hi there.
>
> > In the other day, I downloaded the source of libiconv-1.11 and tried
> > compiling it. Well, an error occurred and the compiling was called
> > off.
> >
> > My compiling steps were as follows.
> >
> > 1.  ./configure --prefix=/mingw --target=mingw --enable-static
> > --enable-extra-encodings --disable-shared
> >
> > 2. After the configure was well completed and the Makefile was
> > generated, I entered the command "make".
> >
> > However, an error occurred when executing the following command.
> >
> > ----  gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
> > "-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
> > -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
> > -DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
> > -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c" -o
> > localcharset.o
> >
> > And the error message is "gcc.exe: no input files".
>
> It seems that this command line is not properly constructed; the quotes
> in the command line might be seen as one long argument, so the -c
> doesn't get noticed; so gcc does not see any input files. For instance,
>
> %cat argv.c
> int main(int argc, char *argv[])
> {
>   printf("argv[1] = %s\n", argv[1]);
>   printf("argv[2] = %s\n", argv[2]);
> }
>
> %./argvc.exe "-1a -2b -3c" -4Im_2_actually
> argv[1] = -1a -2b -3c
> argv[2] = -4Im_2_actually
>
> As a workaround for now, perhaps can you can try entering in the proper
> directory (where make was) and run the command above without the outer
> quotes; if it compiles the file, then you run make again and since the
> file is already compiled, make will try the next step in the compilation
> procedure.
>
> I do not get why the outer quotes are there. A typo perhaps?
>
> > I searched for localcharset.c in the libiconv-1.11 package. It turned
> > out that the localcharset.c is in the directory
> > "./libiconv/libcharset/lib". I just can't understand why the gcc could
> > not find it and what's wrong with my compiling.
>
> To do this sort of checking, you must also account for which current
> directory make was in, since you ran make; notice how make sometimes
> changes directories and issues messages such as ``entering directory''
> and ``leaving directory'' so that also tells where make was when it
> issued a shell command.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

haibin zhang wrote:
> Greg Chicares <chi...@co...> 写道： On 2007-06-25 02:33Z, haibin zhang wrote:
>>*/Yi Yi /* 写道：
>>
>>    And the error message is "gcc.exe: no input files".
>>
>>I really know it , you must use make-3.81 or make-3.80, please check it,
>>don't use them , you must use make-3.79.1
> 
> This advice surprises me, because I have used gcc successfully
> with both make-3.79.1 and make-3.81. But if you are sure about
> this, then please post a complete testcase so that others can
> reproduce the problem and investigate the cause.
> Have you  built libiconv-1.11or other program successfully with both make-3.79.1 and make-3.81 ?  if it is other program , don't see that make-3.81 can build libiconv-1.11, I have built libiconv-1.11, I only can build it with make-3.79.1, I can't build it with make-3.81 and when I build it with make-3.81 , the error same as you.

Any chance of actually marking the quoted text as such?
I read all my mails as text and just keep on skipping over your
mails as duplicates since they look like some kind of echo service (spam).


-- 
Tuomo

... If it is there and you can see it              it is real
    If it is there and you can not see it          it is transparent
    If it is not there and you can see it          it is virtual
    If it is not there and you can not see it      it is gone
                                       -- Roy Wilks 1983, TCP/IP Networking

Greg Chicares <chi...@co...> 写道： On 2007-06-25 02:33Z, haibin zhang wrote:
> 
> */Yi Yi /* 写道：
> 
>     And the error message is "gcc.exe: no input files".
> 
> I really know it , you must use make-3.81 or make-3.80, please check it,
> don't use them , you must use make-3.79.1

This advice surprises me, because I have used gcc successfully
with both make-3.79.1 and make-3.81. But if you are sure about
this, then please post a complete testcase so that others can
reproduce the problem and investigate the cause.
Have you  built libiconv-1.11or other program successfully with both make-3.79.1 and make-3.81 ?  if it is other program , don't see that make-3.81 can build libiconv-1.11, I have built libiconv-1.11, I only can build it with make-3.79.1, I can't build it with make-3.81 and when I build it with make-3.81 , the error same as you.



       
---------------------------------
 雅虎免费邮箱3.5G容量，20M附件！

On 2007-06-25 02:33Z, haibin zhang wrote:
> 
> */Yi Yi <win...@gm...>/* 写道：
> 
>     And the error message is "gcc.exe: no input files".
> 
> I really know it , you must use make-3.81 or make-3.80, please check it,
> don't use them , you must use make-3.79.1

This advice surprises me, because I have used gcc successfully
with both make-3.79.1 and make-3.81. But if you are sure about
this, then please post a complete testcase so that others can
reproduce the problem and investigate the cause.

Yi Yi <win...@gm...> 写道： Hi, everybody .

I'm a newcomer to this mailing-list and a beginner of MinGW+MSYS. Nice
to meet you all.

In the other day, I downloaded the source of libiconv-1.11 and tried
compiling it. Well, an error occurred and the compiling was called
off.

My compiling steps were as follows.

1.  ./configure --prefix=/mingw --target=mingw --enable-static
--enable-extra-encodings --disable-shared

2. After the configure was well completed and the Makefile was
generated, I entered the command "make".

However, an error occurred when executing the following command.

----  gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
"-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
-DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
-DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
-Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c" -o
localcharset.o

And the error message is "gcc.exe: no input files".
I really know it , you must use make-3.81 or make-3.80, please check it, don't use them , you must use make-3.79.1

good luck!

I searched for localcharset.c in the libiconv-1.11 package. It turned
out that the localcharset.c is in the directory
"./libiconv/libcharset/lib". I just can't understand why the gcc could
not find it and what's wrong with my compiling.

Please help me. Your kindness is appreciated.

Thank U in advance.

Cloude Yih

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
Min...@li...
https://lists.sourceforge.net/lists/listinfo/mingw-msys


       
---------------------------------
抢注雅虎免费邮箱3.5G容量，20M附件！ 

On Sunday 24 June 2007 15:38, Yi Yi wrote:
> In the other day, I downloaded the source of libiconv-1.11 and tried
> compiling it. Well, an error occurred and the compiling was called
> off.
>
> My compiling steps were as follows.
>
> 1. =A0./configure --prefix=3D/mingw --target=3Dmingw --enable-static
> --enable-extra-encodings --disable-shared

Another point, which I missed in my earlier reply: you are not building=20
a compiler, or other code generator here, so --target... has no meaning=20
for this package.  It shouldn't hurt, but you have no reason to specify=20
it; better to leave it out.

Regards,
Keith.

On Sunday 24 June 2007 15:38, Yi Yi wrote:
> In the other day, I downloaded the source of libiconv-1.11 and tried
> compiling it. Well, an error occurred and the compiling was called
> off.

GNU libiconv-1.11 builds OOTB, for me using either MSYS-1.0.10, or the 
candidate MSYS-1.0.11.  MSYS-1.0.9 is ancient; I recommend upgrading.

> My compiling steps were as follows.
>
> 1.  ./configure --prefix=/mingw --target=mingw --enable-static
> --enable-extra-encodings --disable-shared

Why disable shared?  I confess I didn't try this.

> 2. After the configure was well completed and the Makefile was
> generated, I entered the command "make".
>
> However, an error occurred when executing the following command.
>
> ----  gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
> "-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
> -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
> -DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
> -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c"
> -o localcharset.o

Did you copy and paste this?  Like Daniel Bastos, I'm puzzled by the 
quoting, especially since the double quotes are unbalanced.

> And the error message is "gcc.exe: no input files".

Which is correct with that quoting, for everything between the first and 
the last double quote is wrapped into a single `-D...' option, leaving 
no source file name visible.

Do please note that GNU libiconv-1.11 does not handle Woe32 wchar_t 
correctly.  There is a patch available, which you can get by building 
using our mingwPORT package:
http://downloads.sourceforge.net/mingw/libiconv-1.11-mingwPORT-20070423-1.tar.bz2

Regards,
Keith.

On 6/24/07, Yi Yi <win...@gm...> wrote:
> Hi, everybody .

Hi there.

> In the other day, I downloaded the source of libiconv-1.11 and tried
> compiling it. Well, an error occurred and the compiling was called
> off.
>
> My compiling steps were as follows.
>
> 1.  ./configure --prefix=/mingw --target=mingw --enable-static
> --enable-extra-encodings --disable-shared
>
> 2. After the configure was well completed and the Makefile was
> generated, I entered the command "make".
>
> However, an error occurred when executing the following command.
>
> ----  gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
> "-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
> -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
> -DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
> -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c" -o
> localcharset.o
>
> And the error message is "gcc.exe: no input files".

It seems that this command line is not properly constructed; the quotes
in the command line might be seen as one long argument, so the -c
doesn't get noticed; so gcc does not see any input files. For instance,

%cat argv.c
int main(int argc, char *argv[])
{
  printf("argv[1] = %s\n", argv[1]);
  printf("argv[2] = %s\n", argv[2]);
}

%./argvc.exe "-1a -2b -3c" -4Im_2_actually
argv[1] = -1a -2b -3c
argv[2] = -4Im_2_actually

As a workaround for now, perhaps can you can try entering in the proper
directory (where make was) and run the command above without the outer
quotes; if it compiles the file, then you run make again and since the
file is already compiled, make will try the next step in the compilation
procedure.

I do not get why the outer quotes are there. A typo perhaps?

> I searched for localcharset.c in the libiconv-1.11 package. It turned
> out that the localcharset.c is in the directory
> "./libiconv/libcharset/lib". I just can't understand why the gcc could
> not find it and what's wrong with my compiling.

To do this sort of checking, you must also account for which current
directory make was in, since you ran make; notice how make sometimes
changes directories and issues messages such as ``entering directory''
and ``leaving directory'' so that also tells where make was when it
issued a shell command.

Hi, everybody .

I'm a newcomer to this mailing-list and a beginner of MinGW+MSYS. Nice
to meet you all.

In the other day, I downloaded the source of libiconv-1.11 and tried
compiling it. Well, an error occurred and the compiling was called
off.

My compiling steps were as follows.

1.  ./configure --prefix=/mingw --target=mingw --enable-static
--enable-extra-encodings --disable-shared

2. After the configure was well completed and the Makefile was
generated, I entered the command "make".

However, an error occurred when executing the following command.

----  gcc -I. -I. -I.. -I./.. -I../include -g -O2 -fvisibility=hidden
"-DLIBDIR=\\/mingw/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL
-DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/mingw/lib\"
-DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix
-Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c" -o
localcharset.o

And the error message is "gcc.exe: no input files".

I searched for localcharset.c in the libiconv-1.11 package. It turned
out that the localcharset.c is in the directory
"./libiconv/libcharset/lib". I just can't understand why the gcc could
not find it and what's wrong with my compiling.

Please help me. Your kindness is appreciated.

Thank U in advance.

Cloude Yih

"Daniel C. Bastos" <db...@to...> wrote:
> Hi.
>
> I currently keep my .emacs in c:\ and in ~/ in msys. I tried putting it
> in c:\emacs and in c:\emacs\bin, but emacs seems to ignore them there.
>
> [snip]
>
> But how do you guys keep your .emacs in one place?
>
> I need it in both places because emacs reads c:\.emacs when I call it
> from a Windows hotkey, and it reads ~/.emacs when called from msys.
>   
In Windows, set the HOME environment variable with a directory of your 
choosing (it doesn't have to be your MSYS ~/ directory, but perhaps it 
should be) and put your .emacs file in this directory.  Emacs will then 
pick up your .emacs file from both environments.

Curt

Daniel C. Bastos wrote:
> 
> If I can get this flag to work, then my problem is solved. What I
> currently do is use a script that copies the .emacs from /c/ to ~/
> before it loads emacs from the shell. But how do you guys keep your
> .emacs in one place?
> 
> I need it in both places because emacs reads c:\.emacs when I call it
> from a Windows hotkey, and it reads ~/.emacs when called from msys.

You could try defining a Windows environment variable HOME that points to your
MSYS home directory

Hi.

I currently keep my .emacs in c:\ and in ~/ in msys. I tried putting it
in c:\emacs and in c:\emacs\bin, but emacs seems to ignore them there.

The manual says

The Init File, `~/.emacs'
=========================

  When Emacs is started, it normally loads a Lisp program from the file
`.emacs' or `.emacs.el' in your home directory.  We call this file your
"init file" because it specifies how to initialize Emacs for you.  You
can use the command line switch `-q' to prevent loading your init file,
and `-u' (or `--user') to specify a different user's init file (*note
Entering Emacs::).

But I couldn't get -u or --user to work. I tried

%emacs -u /c/emacs/.emacs
%emacs --user /c/emacs/.emacs
%emacs -u 'c:\emacs\.emacs'
%emacs --user 'c:\emacs\.emacs'

and they all load the GNU emacs with a white background which tells me
that my .emacs was not loaded.

%cat /c/emacs/.emacs | grep background
(set-background-color "black")

If I can get this flag to work, then my problem is solved. What I
currently do is use a script that copies the .emacs from /c/ to ~/
before it loads emacs from the shell. But how do you guys keep your
.emacs in one place?

I need it in both places because emacs reads c:\.emacs when I call it
from a Windows hotkey, and it reads ~/.emacs when called from msys.

On 6/19/07, Andrzej Ziarkowski <zi...@gm...> wrote:
>
> i'm totally newbie with sed/MSYS. I tried to madofy one simply batch file,
> but i got problems with path convertion.
>
> I have "small problem" with sed in my windows batch file: the output file
> is not included any slash in the file path.
> I mean that from my variable UNLOADFILE "C:\Temp\biblio.001" sed is making
> "C:Tempbiblio.001".
>
> How i can stoping this behavior of sed?


This is just the way MSYS works. You might be able to work around it, but I
your case I would look for a little free program called gsar.exe (General
Search And Replace) by Tormod Tjaberg and Hans Peter Verne. I have version
1.11 on my PC.

Andrzej Ziarkowski wrote:
> i'm totally newbie with sed/MSYS. I tried to madofy one simply
> batch file, but i got problems with path convertion.

Are you trying to run windows batch files from the MSYS prompt?
If so, you really need to know a lot about what you are doing, for
this is not straightforward -- not something for newbies to try!

> I have "small problem" with sed in my windows batch file: the
> output file is not included any slash in the file path.

Or, are you trying to run MSYS commands, (sed in this case), from
a cmd.exe prompt?  (This would be the same as using MSYS commands
within a Woe32 batch file).  This is more achievable, but again,
it helps if you know what you are doing.

> I mean that from my variable UNLOADFILE "C:\Temp\biblio.001" sed
> is making "C:Tempbiblio.001".
>
> How i can stoping this behavior of sed?

sed is a POSIX command, and it uses backslashes as literal escapes;
if you want to pass them through, so they can be seen as dir/file
name separators in Woe32's dyslexic manner, then you have to escape
them; (POSIX uses a regular slash as the dir/file name separator).
Thus, you need "C:\\Temp\\biblio.001".

Since you profess to be a newbie, I'd really recommend *not* trying
to mix MSYS/POSIX and Woe32/cmd.exe syntax in the same environment;
use MSYS commands with POSIX syntax from the MSYS bash prompt, or in
sh scripts, and don't try to use them from cmd.exe.

HTH,
Keith.

Andrzej Ziarkowski wrote:

> Hallo,
>
> i'm totally newbie with sed/MSYS. I tried to madofy one simply batch file, but i got problems with path convertion.
>
> I have "small problem" with sed in my windows batch file: the output file is not included any slash in the file path.
> I mean that from my variable UNLOADFILE "C:\Temp\biblio.001" sed is making "C:Tempbiblio.001".
>

I suggest these things to try instead of  "C:\Temp\biblio.001"

1.  "C:\\Temp\\biblio.001"
2.  "C:/Temp/biblio.001"
3.  "/C/Temp/biblio.001"
4.  "/C:/Temp/biblio.001"

Tim S

Hallo,

i'm totally newbie with sed/MSYS. I tried to madofy one simply batch file, but i got problems with path convertion.

I have "small problem" with sed in my windows batch file: the output file is not included any slash in the file path.
I mean that from my variable UNLOADFILE "C:\Temp\biblio.001" sed is making "C:Tempbiblio.001".

How i can stoping this behavior of sed?

****** BATCHFILE test.bat *******
REM %1 = Databasename
REM %2 = Unloadfile

@ECHO OFF
CLS
SETLOCAL
SET DBNAME=ISLAND
SET SERVERNAME=SERVICE
SET TEMP=C:\TEMP
SET UNLOADFILE=C:\TEMP\BIBLIO.001
IF NOT "%1" == "" SET DBNAME=%1
IF NOT "%2" == "" SET UNLOADFILE=%2

sed -e "s/<dbname>/%DBNAME%/" -e "s/<unloadfile>/%UNLOADFILE%/" -e "s#<servername>#%SERVERNAME%#" N:\Service\DB\load_DBS.sql >%temp%\%DBNAME%.in

TYPE %TEMP%\%DBNAME%.in
ENDLOCAL
****** END OF BATCHFILE test.bat *******

And this is a badly generated file %DBNAME%.in :
******** BAD FILE *********
<cutted>
LOAD SQL C:TEMPbiblio.sql ON SERVER LOG k1234.LOG
<cutted>
******** END OF BAD FILE *********

Thx in advance
Andrzej
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Michael Chen wrote:
> Dear there,

"There"?

> I am compiling CEPHES Math Library, http://www.moshier.net/double.zip.
> With slight change of the given default unix makefile, I can compile
> the library. however I don't know how to  generate its header file.
> Any suggestions? Thanks in advance.

How about http://www.moshier.net/cephes-math-28.tar.gz ?

Anyway, this has probably nothing to do with MinGW.
See the end of http://www.moshier.net/index.html.
There's contact info for some guy named Steve there. I suspect he may
be able to assist you further.


-- 
Tuomo

... Verbosity leads to unclear, inarticulate things

Dear there,

I am compiling CEPHES Math Library, http://www.moshier.net/double.zip.
With slight change of the given default unix makefile, I can compile
the library. however I don't know how to  generate its header file.
Any suggestions? Thanks in advance.

--
Michael Chen

Hi,

I am facing a problem that disturbs me as I can't explain it ;-)
Let's consider this C file:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
  int i = 0;
  char *p = NULL;
  for (i = 1 ; i < argc; i++) {
    p = getenv(argv[i]);
    fprintf(stdout, "var = %s\nval = %s\n\n", argv[i], p);
  }
  return 0;
}

I have a makefile I currently use on Unix-like platforms (solaris, 
linux, cygwin):
XCFLAGS =
OPT=${DEVPACKROOTPATH}
export CFLAGS = -I. $(OPT)
export LDFLAGS = $(OTHER_X_LDFLAGS) $(OPT)
HOST_CC=gcc
HOST_CFLAGS=-O0
%.exe: %.c
    $(HOST_CC) $(HOST_CFLAGS) $< -o $@
all: driver
driver: expand.exe
    ./$< CFLAGS LDFLAGS


 From a msys windows, I define the DEVPACKROOTPATH environment variable:
'export DEVPACKROOTPATH=y:/ScDevTools/v2.1'
and type:
'make all'
then I obtain:
var = CFLAGS
val = -I. y:/ScDevTools/v2.1
 
var = LDFLAGS
val =  y;C:\msys\1.0\ScDevTools\v2.1

Why the first expansion is correct and why not the secund one?

After reading the MSYS readme, I currently work around this problem by 
setting the DEVPACKROOTPATH variable to /y/ScDevTools/v2.1.
But that doesn't explain why the first expansion is correct and why not 
the secund one!

Any ideas?

I am using MSYS 1.0.11 with sh 2.04.0, make 3.79.1 and gcc 3.4.2.

Thank you in advance for your support.

-- JM

Michael Chen wrote:
> I am trying to use etags to generate tag files for emacs, and the
> following command works under linux environment, but failed under
> MSYS 1.0
>
> etags --language=none --regex='/[ t]*param[ \t]+\([^ \t]+\)/\1/' \
>  blendingexample.mod
>
> Error Msg:
>
> e:\chen\programs\emacs\emacs-21.3\bin\etags.exe:
> E:/chen/programs/msys/1.0/[ t]*param[ /t]+/([^ /t]+/)//1/:
> unterminated regexp

This appears to be yet another manifestation of the automatic path
name translation, performed by MSYS when passing arguments to native
Woe32 programs, interfering with your intended purpose.  In this
case, MSYS is mistaking your --regex expression for a path name,
expressed in MSYS-POSIX form, and is "helpfully" converting it
to native Woe32 form.

Unfortunately there is no way, with existing MSYS implementations,
to override this behaviour, beyond the existing double slash hack
for passing options to brain dead M$ style programs, which don't
recognise `-' as a SWITCHAR; (and unfortunately, this hack doesn't
seem to help, in this particular case, since the reduction of the
initial slashes doesn't occur when another slash appears later in
the argument):

  $ cmd //c echo --regex='/[ t]*param[ \t]+\([^ \t]+\)/\1/'
  "--regex=D:/usr/MSYS-1.0.11/[ t]*param[ /t]+/([^ /t]+/)//1/"

  $ cmd //c echo --regex='//[ t]*param[ \t]+\([^ \t]+\)/\1/'
  "--regex=//[ t]*param[ /t]+/([^ /t]+/)//1/"

Notice how doubling the initial slash avoids the substitution of
the MSYS root path, but still leaves a malformed regex because the
extra slash is not removed; I'm convinced this is a bug in the
MSYS path translation logic.

Also notable is that the backslash of the `\1' substitution term
has been transliterated, becoming `/1', and similarly for the `\t'
substitutions, becoming `/t'; yet another bug.

Do notice that this same problem affects sed regexes, if you use
a non-MSYS implementation of sed.  In that case, it is often
possible to work around the issue, by choosing an alternative
delimiter character to `/', for regexes; e.g. parsing the text of
this message, (before pasting in this example):

  $ sed -n '\?trans?p' mail.txt
  name translation, performed by MSYS when passing ...
  MSYS path translation logic.
  has been transliterated, becoming `/1', ...

I'm not an emacs user, so I don't know if a similar workaround is
possible with etags:

  $ cmd //c echo --regex='\?[ t]*param[ \t]+\([^ \t]+\)?\1?'
  "--regex=\?[ t]*param[ \t]+\([^ \t]+\)?\1?"

If not, then I don't think you are going to have much success
using etags in MSYS, until we can develop a suitable fix for this
long-standing bug, unless you can build etags as an msys-1.0.dll
dependent application.

Regards,
Keith.

I am trying to use etags to generate tag files for emacs, and the
following command works under linux environment, but failed under MSYS
1.0

etags --language=none --regex='/[ t]*param[ \t]+\([^ \t]+\)/\1/'
blendingexample.mod

Error Msg:

e:\chen\programs\emacs\emacs-21.3\bin\etags.exe:
E:/chen/programs/msys/1.0/[ t]*param[ /t]+/([^ /t]+/)//1/:
unterminated regexp

And I tried quite a while to make it work, following are interesting tries:

(1)
etags --language=none --regex=' /[ t]*param[ \t]+\([^ \t]+\)/\1/'
blendingexample.mod

note the space after ='

MSYS doesn't complain  "unterminated regexp" for this one. but the
produced TAGS file has no match at all.

(2)
etags --language=none --regex=' [ t]*param[ \t]+\([^ \t]+\)/\1'
blendingexample.mod

note the space after ='   and the two "/" being removed. Same result as in (1)


Can anybody help?

Michael

===============
blendingexample.mod
===============
var v {1..4};
param y {1..2};
minimize Obj:
5*v[1]+13*v[2]+26*v[3]+45*v[4]-2;
subject to Con1:
y[1]+2*y[2]=v[2]+2*v[3]+3*v[4];
subject to Con2:
y[1]+3*y[2]-1=v[2]+4*v[3]+10*v[4];
subject to Con3:
v[1]+v[2]+v[3]+v[4]>=0;
subject to Con4:
v[1]+2*v[2]+3*v[3]+4*v[4]>=0;
subject to Con5:
v[1]+3*v[2]+6*v[3]+10*v[4]>=0;
subject to Con6:
v[1]+4*v[2]+10*v[3]+20*v[4]>=0;

data;
param y:=
1 3
2 -1
;

Just so that the list knows, I'm working with Keith and James on
getting something done about Vista64. My original patch seems to have
issues with windows XP (it makes some processes hang every once in a
while). I think I have a better patch, but it needs testing.

Cheers,

-Oscar

On Sat, Jun 02, 2007 at 09:51:26PM -0700, James Darpinian wrote:
> OK, I've tested the patch for the Vista 64 crashing bug and fixed an issue
> with it; I've submitted the fixed patch to the tracker.  With this patch
> MSYS seems to work fine; I am currently compiling Mozilla Firefox with it.
> What's the next step in getting the patch committed?
> 
> James
> -- 
> main(c,r){for(r=32;r;)printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}

> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys


-- 
pgp fingerprint: BC64 2E7A CAEF 39E1 9544  80CA F7D5 784D FB46 16C1