Hi,

It seems fpc converts under Windows \^ to ^.
See here:

http://bugs.freepascal.org/view.php?id=23294

Is this a feature or a bug?

Mattias

In our previous episode, Mattias Gaertner said:

No idea, but IIRC ^ is the escape char on Windows NT cmdline shell (like \ in C).

So ^\ would be a non-path "\" ?!?

I don't know how deep it goes and if it is cmd.exe only.

C:\Users\^-^\AppData is converted to C:\Users^-^\AppData.

If ^ is the escape character then it is strange that ^\ is kept and the \^ is not.

Mattias

Fpc ParamStr() handles the \^-^\ part correctly it seems (see bugreport).

Bart

Fpc ParamStr() handles the \^-^\ part correctly it seems (see bugreport).

'make' writes the right file name. Next thing is FPC and that uses the wrong path. So either 'make' is lying or FPC alters the path.

In either case it is more a FPC issue than a Lazarus issue. The bug report should be moved to FPC.

Mattias

The compiler does not seem to have problems with constructs like:

fpc c:\path\^-^\foo.pp @c:\path\^-^\^-^\foo.cfg at all (see bugreport for an example).

(Maybe make is lying?)
Does fpc have a switch to echo all commandline parameters (would be nice for this issue)?

Someone should be brave enought to try and replicate/confirm the described problem.

Bart

In our previous episode, Bart said:

Maybe the ^-as-an-escape is a shell-only convention. The compiler doesn't work through the shell. Make probably does.

Marco van de Voort wrote

Maybe the ^-as-an-escape is a shell-only convention. The compiler doesn't work through the shell. Make probably does.

But then the shell would make it \-\.

Converting SomePath\^-^\SomePath into SomePath^-^\SomePath looks more like C...

Bart

In our previous episode, Bart said:

But then the shell would make it \-\. Converting SomePath\^-^\SomePath into SomePath^-^\SomePath looks more like C...

Make could also be doing own substitutions, so is not a good testing platform to draw conclusions off. Note that I haven't tested that much, I just saw the hint about ^ being NT escape, and guessed the rest pretty much.

Bart wrote

Someone should be brave enought to try and replicate/confirm the described problem.

Just did that, and indeed the error occurred.
So, confirmed.

Bart

I took a look at Microsoft's documentation and indeed found something. Take a look here
http://technet.microsoft.com/en-us/library/cc723564.aspx and look for "Figure 2.3: Simple command syntax". Below that are some bullets where the fourth mentions the reserved characters for the NT shell which includes "^" which is the escape character (unlike "\" in sh and C). So the carat needs to be escaped as "^^".

As a sidenote: I didn't know up to now that the prompt in the NT shell can also be modified O.o

Note 2: Maybe the PowerShell will have a bit different rules, I don't know...

Regards,
Sven

Sven Barth wrote

Note 2: Maybe the PowerShell will have a bit different rules, I don't know...

The PowerShell uses ` (back quote) as escape character...

Regards,
Sven

On 28 Apr 13, at 21:03, Sven Barth wrote:
.
.

As a sidenote: I didn't know up to now that the prompt in the NT shell can also be modified O.o

.
.

Setting the PROMPT variable works for all DOS-like platforms (MS-DOS and compatibles, OS/2 and MS Windows NT+ and also replacement shells like those from JPSoft), although the set of supported metacodes varies slightly among them, of course (and the full set of possibilities also depends on other aspects like console features including ANSI positioning and colour commands, etc.).

Tomas