BUG? configure: Unknown option: --prefix=/usr

[arfon]

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.

[Rubidium]

Use --prefix-dir.

[arfon]

May I suggest adding --prefix as a recognized option since it seems to be more standard in the Linux world?

[TrueBrain]

Standards and -- options don't mix in the current world. One of the very annoying things ....

[PhilSophus]

Standards and -- options don't mix in the current world. One of the very annoying things ....

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 )

[Thief^]

I'd have tried " -?".

[TrueBrain]

I'd have tried " -?".

That would have failed (-h works)

[PhilSophus]

I'd have tried " -?".

That would have failed (-h works)

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

*ROFL* I guess it does, what I think it does, unless a shell does think it should do different (hint: touch -- -x )

Wow, it now shows the help on any unknown option, so my little trick failed

[Thief^]

Heheh, I'm in the commit logs again

[PhilSophus]

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

Hehe, now it breaks as expected

Oh, I should better not forget to remove the file again

[TrueBrain]

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

Hehe, now it breaks as expected

Oh, I should better not forget to remove the file again

That you can only blame on your shell

[PhilSophus]

Code: Select all

$ touch -- -x
$ ./configure -?
Unknown option -x

Hehe, now it breaks as expected

That you can only blame on your shell [/quote]
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.

[Thief^]

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.

[PhilSophus]

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.

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.

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.

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^]

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?

[PhilSophus]

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?

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.

Code: Select all

$ shopt -s failglob
$ ./configure -?
bash: no match: -?

(Even worse if nullglob is set and failglob is not, then -? will be expanded to nothing and configure will be called without arguments, i.e. causing it to be actually run).


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).

[TrueBrain]

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

[DaleStan]

You might get saner results if you mixed back-slash escaping and quoting -- "*.tif" instead of \*.tif, for example.