thanks for the explanation. I moved getopt.exe to the dir where the script is and
sh miktex_update --help work, miktex_update --version work.
Thanks for the help.
--- On Thu, 6/12/08, Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx> wrote:
From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Mingw-msys] getopt error in msys Version 1.0.10
Date: Thursday, June 12, 2008, 3:05 PM
On Wednesday 11 June 2008 13:54, Michael DOUBEZ wrote:
> Ardi a écrit :
> binary would be more than enough for me.
> > [...snip...]
> I put it at the following address:
For some reason, this is the only message I've received, from this
thread; reconstructing from the GMANE archive...
> > miktex_update: getopt: command not found
> Unless someone does it for you, you have two solution:
> - compile getopt: grab the linux-util sources from
> ftp://ftp.kernel.org/pub/linux/utils/util-linux/ and try to compile
> the getopt program. I did give it a quick try and got an error at
> getopt.o:getopt.c:(.text+0x25e): undefined reference to
> You can just comment out the "_only" at the offending line. You
> be able to have long option only but it should be fine for your need.
Ah, but I *did* want getopt_long_only(),
(for an unrelated application),
so I've provided a replacement for the current MinGW getopt(3) code; you
will find it in our CVS repository:
> If you want the binary I have made, email me. I give no guarantee
> about it working on your computer :).
And, judging from the OP's response...
| I have copied getopt.exe to msys/1.0/bin directory
| but using sh miktex_update -h it gives error:
...it didn't! However, unless Michael built it using the special MSYS
development tools, this is only to be expected, because the OP is using
MSYS-1.0.10, and as Cesar has already explained, non-MSYS executables in
the MSYS /bin directory just will not work; you should either create
a /local/bin directory, (mapped, by an MSYS automatic loop back mount,
to /usr/local/bin, which should already be in the
$PATH), and put such
executables there, or, again as Cesar has suggested, put them in some
other directory of your choice, which is included in your $PATH.
> - Change the script in order to use getopts instead of getopt but
> then you won't be able to use the long options.
Well, getopts is not a drop in substitute for getopt; to make that work,
some additional effort is required. In fact, it is perfectly feasible
to use getopts, and to retain a long options capability; that too just
entails a bit of effort. For working examples, see:
(Neither of which actually use either getopt or getopts, but neither is
precluded; I have previously used this technique together with getopts,
but I don't seem to have an example readily to hand).
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Mingw-msys mailing list