BUG? configure: Unknown option: --prefix=/usr
Moderator: OpenTTD Developers
BUG? configure: Unknown option: --prefix=/usr
This seems like a bug in ./configure but when you pass the '--prefix' option to configure, it returns: "Unkown option: --prefix=/usr"
I was compiling (0.6.3) on Slackware when this happened using src2pkg. I went ahead and manually compiled OpenTTD and successfully made a Slackware package but, the --prefix option is very useful and the configure script should recognize it.
I was compiling (0.6.3) on Slackware when this happened using src2pkg. I went ahead and manually compiled OpenTTD and successfully made a Slackware package but, the --prefix option is very useful and the configure script should recognize it.
Re: BUG? configure: Unknown option: --prefix=/usr
Use --prefix-dir.
Re: BUG? configure: Unknown option: --prefix=/usr
May I suggest adding --prefix as a recognized option since it seems to be more standard in the Linux world?
Re: BUG? configure: Unknown option: --prefix=/usr
Standards and -- options don't mix in the current world. One of the very annoying things ....
The only thing necessary for the triumph of evil is for good men to do nothing.
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
As long as --help is recognized that shouldn't be a big problem. I mean that is the second quasi-standard option I'd try after the first one didn't work. And indeed, that one works as expected and solves any such issue (third one would have been -h if you wondered )TrueBrain wrote:Standards and -- options don't mix in the current world. One of the very annoying things ....
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
I'd have tried " -?".
Melt with the Shadows,
Embrace your destiny...
Embrace your destiny...
Re: BUG? configure: Unknown option: --prefix=/usr
That would have failed (-h works)Thief^ wrote:I'd have tried " -?".
The only thing necessary for the triumph of evil is for good men to do nothing.
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
TrueBrain wrote:That would have failed (-h works)Thief^ wrote:I'd have tried " -?".
*ROFL* I guess it does, what I think it does, unless a shell does think it should do different (hint: touch -- -x )changeset: 10408:64f14ac71cc6
user: truebrain
date: Sat Dec 06 00:38:48 2008 +0000
summary: (svn r14659) -Add: in case Thief^ (forum user) ever tries what he thinks he will try when he doesn't know it is --prefix-dir, make sure he also gets what he assumes he gets
Wow, it now shows the help on any unknown option, so my little trick failed
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
Heheh, I'm in the commit logs again
Melt with the Shadows,
Embrace your destiny...
Embrace your destiny...
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
r14661 | truebrain | 2008-12-07 13:41:20 +0100 (Sun, 07 Dec 2008) | 2 lines
-Fix r14659: oops, forgot to escape '?'
Code: Select all
$ touch -- -x
$ ./configure -?
Unknown option -x
Oh, I should better not forget to remove the file again
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
That you can only blame on your shellPhilSophus wrote:r14661 | truebrain | 2008-12-07 13:41:20 +0100 (Sun, 07 Dec 2008) | 2 lines
-Fix r14659: oops, forgot to escape '?'Hehe, now it breaks as expectedCode: Select all
$ touch -- -x $ ./configure -? Unknown option -x
Oh, I should better not forget to remove the file again
The only thing necessary for the triumph of evil is for good men to do nothing.
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
That you can only blame on your shell [/quote]TrueBrain wrote:Hehe, now it breaks as expectedCode: Select all
$ touch -- -x $ ./configure -? Unknown option -x
Well, given that neither nullglob nor failglob are set in my bash, and I usually don't create files starting with a dash it will usually work as expected , but in which shell it isn't a wildcard (AFAIR it even is one in Windows, as well, isn't it?)
Anyway, my joke has a serious background. If someone executes commands in a directory not owned by himself, he could be tricked to execute the command with an unwanted option, thereby causing damage instead of getting help. So, in general commands shouldn't offer -? so that user don't get used to it. It's not a big issue here, just general caution.
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
Shouldn't the program require "--" to use any filenames that start with a dash? Wildcard or not? Like touch in your example. Or at least quotes around it.
EDIT: On Windows -? or /? are the standard ways to get help. Regardless of the system, an unrecognised parameter should print the help, or instructions to get help.
EDIT: On Windows -? or /? are the standard ways to get help. Regardless of the system, an unrecognised parameter should print the help, or instructions to get help.
Melt with the Shadows,
Embrace your destiny...
Embrace your destiny...
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
That's exactly the point, but the shell doesn't care and does the wildcard expansion before the program sees it. So, the shell expands it to -f if a file named -f exists and the program interprets it as an option. Just imagine the command you wanted the help for, was a very destructive one and -f (force) was the switch to proceed without questions.Thief^ wrote:Shouldn't the program require "--" to use any filenames that start with a dash? Wildcard or not? Like touch in your example. Or at least quotes around it.
Hmm, it has been quite a time, since I programmed something for Windows, but IIRC wildcard expansion isn't done by the shell in Windows but has to be done by the program itself. So, it can sort out its options before.Thief^ wrote: EDIT: On Windows -? or /? are the standard ways to get help. Regardless of the system, an unrecognised parameter should print the help, or instructions to get help.
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
Isn't it a bug that the shell expands the wildcard assuming that it is a file, but the program is interpreting it as a parameter? Surely the expected behaviour if you were using the "?" as a wildcard would be to have the program interpret it as a file?
Melt with the Shadows,
Embrace your destiny...
Embrace your destiny...
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: BUG? configure: Unknown option: --prefix=/usr
It's not a bug of the shell. The bash man page for example carefully specifies which expansions are done in which order. It doesn't try to be clever how a program may interpret the result. If the user writes a wildcard he better means a wildcard (if he means the literal ? he better escapes it). The program, has no chance to see what was originally a wildcard and depending on shell configuration it is even an error to use a wildcard pattern that does not match any file.Thief^ wrote:Isn't it a bug that the shell expands the wildcard assuming that it is a file, but the program is interpreting it as a parameter? Surely the expected behaviour if you were using the "?" as a wildcard would be to have the program interpret it as a file?
Code: Select all
$ shopt -s failglob
$ ./configure -?
bash: no match: -?
That's why I said it might be a bit doubtful (calling it a bug might be a bit to strong) when a program running (among others) in an UN*X environment accepts -? as a parameter (though I've seen many that do).
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: BUG? configure: Unknown option: --prefix=/usr
Then again, any sane user creating \-? files on their disk, is nuts
It always annoys the hell out of me that you can't simply disable the wildcard lookup in, say, bash. A simple example what I tried to do the other day:
unzip <file1> *.tif
unzip <file2> *.tif
The first one worked, there was no *.tif file yet in the dir. The second one failed, as bash was so kind to lookup any .tif file in the dir, and replace it, making unzip unable to find the *.tif inside the <file2> archive. So you need to escape '*' ... silly ....
Back to OpenTTD, there is another annoying problem related to this. To cache the configure options so we can auto-reconfigure on a later moment, we write all configure options to a file. And you can guess it, that needs to be escaped. This is hell. I believe it turned out that I needed 6 forward slashes to just escape a single thing. I really really really hate all those 'glob' helpers of those shells, and wish it worked the other way around: you need to give explicitly when you want it to lookup something, else it just passes it on ... but oh well
It always annoys the hell out of me that you can't simply disable the wildcard lookup in, say, bash. A simple example what I tried to do the other day:
unzip <file1> *.tif
unzip <file2> *.tif
The first one worked, there was no *.tif file yet in the dir. The second one failed, as bash was so kind to lookup any .tif file in the dir, and replace it, making unzip unable to find the *.tif inside the <file2> archive. So you need to escape '*' ... silly ....
Back to OpenTTD, there is another annoying problem related to this. To cache the configure options so we can auto-reconfigure on a later moment, we write all configure options to a file. And you can guess it, that needs to be escaped. This is hell. I believe it turned out that I needed 6 forward slashes to just escape a single thing. I really really really hate all those 'glob' helpers of those shells, and wish it worked the other way around: you need to give explicitly when you want it to lookup something, else it just passes it on ... but oh well
The only thing necessary for the triumph of evil is for good men to do nothing.
Re: BUG? configure: Unknown option: --prefix=/usr
You might get saner results if you mixed back-slash escaping and quoting -- "*.tif" instead of \*.tif, for example.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: No registered users and 6 guests