News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

makeobj does not understand backslashes in arguments

Started by gauthier, April 19, 2017, 05:12:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gauthier

With makeobj 60 for windows, with sources of pak128:

cd pak128
makeobj.exe pak128 catenary.all.pak infrastructure/catenary_all/
:: everything goes well, logs for reading dat files and log for writing pak files are present.
makeobj.exe pak128 catenary.all.pak infrastructure\catenary_all\
:: outputs an empty pak file (an error would be nice in such cases), only log for writing pak file is present.

EDIT 2 (got confused again ...):

makeobj.exe pak128 catenary.all.pak infrastructure/catenary_all
:: does not work
makeobj.exe pak128 catenary.all.pak infrastructure/catenary_all/
:: works
makeobj.exe pak128 catenary.all.pak ./infrastructure/catenary_all
:: does not work
makeobj.exe pak128 catenary.all.pak ./infrastructure/catenary_all/
:: works

makeobj.exe pak128 catenary.all.pak infrastructure\catenary_all
:: does not work
makeobj.exe pak128 catenary.all.pak infrastructure\catenary_all\
:: does not work
makeobj.exe pak128 catenary.all.pak .\infrastructure\catenary_all
:: does not work
makeobj.exe pak128 catenary.all.pak .\infrastructure\catenary_all\
:: does not work

prissi

That entirely depends on the compiler and library used, since makeobj is using the standard library calls (fopen and the like) and their interpretation of backlashes is mostly like C, i.e. "\n" stands for new line "\t" for tab, and only "\\" for backlash. Hence convention for filenames is to accept also "/" for backlashes.

However, on older Mac that would both have failed, those used ":" for path seperators. (And I am not sure about our Amiga firends.) Hence, best do not use path in the dat files at all.

gauthier

If I follow you here, that means that somewhere in the code the backslahes in my arguments are interpreted as escaping the next character. That should not happen. I'm used to fopen or even open in C and never had problems with them not accepting backslashes. My arguments should be well translated to the equivalent of a hardcoded "blah\\blah\\blah" and not "blah\blah\blah", should'nt they ?

Ters

The escaping nature of backslashes in C at compile time are irrelevant here (unless you are calling makeobj from a C/C++ program). However, for all I know, you might be using a shell which treats backslashes as escape characters.

gauthier

QuoteThe escaping nature of backslashes in C at compile time are irrelevant here
I know and that's not what I said. I said that something might, at runtime, escape the backslashes after retrieving command line arguments. A shell that escapes characters itself ? Never saw that ... Here it's the Windows console and it does not escapes characters itself before passing strings as arguments.

Ters

Quote from: gauthier on April 20, 2017, 07:57:22 PM
I know and that's not what I said.
That part was me sort of agreeing with you and stating that some of what prissi wrote was something of a digression.

Quote from: gauthier on April 20, 2017, 07:57:22 PM
A shell that escapes characters itself ? Never saw that ... Here it's the Windows console and it does not escapes characters itself before passing strings as arguments.
Except for Microsofts Command Prompts, every other shell that I know of needs escaping since they parse the command line to do wildcard expansion and argument splitting. Microsoft's OSes leave this to the C runtime, although Microsoft's shell still needs to split the program name from the rest, so there might be some such handling in the shell. And I'm not sure who is responsible for variable expansion. However, the shells (or the runtime) do not escape, the user is the one escaping, because the shell (or runtime) puts special meaning into certain characters like space, quotation mark and asterisk. Like C, most shells (being of Unix origin like C) use backslash to escape these characters. Had you been using any other shell except the typical Microsoft ones (don't know about PowerShell), that would have explained why backslashes were not working. The shell would have understood them as you using them to escape some other character. It is not too strange for people to use other shells on Windows since the default one is rather lacking in features compared to shells like bash. It could therefore be that what makeobj sees are the three parameters "pak128", "catenary.all.pak" and ".nfrastructureatenary_all" (or even a bit weirder) when backslashes were used, because the shell treated the backslashes as escapes.

Once it the parameters had gotten that far, nothing should treat the backslashes as special anymore. At least on Windows. Unless, of course, the strings are parsed as a regex pattern or something.

An_dz

In PowerShell you have to escape characters, but since the escaping character is the grave accent it doesn't make much difference. The same applies to CMD, where the escaping character is the caret char ^. Meaning both see the backslash as a normal character and not as a special thing.

prissi

The recently incorporated patch assumed / as separator in paths for wildcards only. That would also choke simutrans for some directory paths. Hopefully rectified in r8214

gauthier

QuoteThat part was me sort of agreeing with you and stating that some of what prissi wrote was something of a digression.
Sorry, did not understand it that way  :-X

QuoteExcept for Microsofts Command Prompts, every other shell that I know of needs escaping since they parse the command line to do wildcard expansion and argument splitting. Microsoft's OSes leave this to the C runtime, although Microsoft's shell still needs to split the program name from the rest, so there might be some such handling in the shell. And I'm not sure who is responsible for variable expansion. However, the shells (or the runtime) do not escape, the user is the one escaping, because the shell (or runtime) puts special meaning into certain characters like space, quotation mark and asterisk. Like C, most shells (being of Unix origin like C) use backslash to escape these characters. Had you been using any other shell except the typical Microsoft ones (don't know about PowerShell), that would have explained why backslashes were not working. The shell would have understood them as you using them to escape some other character. It is not too strange for people to use other shells on Windows since the default one is rather lacking in features compared to shells like bash. It could therefore be that what makeobj sees are the three parameters "pak128", "catenary.all.pak" and ".nfrastructureatenary_all" (or even a bit weirder) when backslashes were used, because the shell treated the backslashes as escapes.
Good to know, anyway I never ran into such problems, that would be surprising ... needs some tests, but my old PC with windows is back on its shelf now and I'm too lazy to take it back :p