Menu
▾
▴
gnuplot-beta
|
From: Martin H. <mar...@gm...> - 2005-11-13 10:47:57
|
Dear all, I just compiled the current CVS HEAD to update my Gnuplot installation. Unfortunately I am unable to change to any root folder (on Windows). If I type in "cd 'C:\'" I get the following error: Can't change to this directory The same applies to D:\ etc. (any root folder). Is that only me or is it a bug? With regards, Martin. |
|
From: Petr M. <mi...@ph...> - 2005-11-13 14:28:06
|
> I just compiled the current CVS HEAD to update my Gnuplot installation.
> Unfortunately I am unable to change to any root folder (on Windows). If
> I type in "cd 'C:\'" I get the following error:
> Can't change to this directory
> The same applies to D:\ etc. (any root folder). Is that only me or is it
> a bug?
It is a bug.
Can be reproduced in this way:
gnuplot> set title 'c:\'
gnuplot> show title
title is "c:\\'", offset at ((character units) 0, 0, 0)
It seems routine try_to_get_string() returns one superfluous ' more. This
routine calls const_express() ... fixing this needs an expert.
---
PM
|
|
From: Martin H. <mar...@gm...> - 2005-11-19 15:07:29
|
Dear all,
I've watched this discussion and actually I didn't expect that it
becomes that difficult and goes into such deep discussion. I would like
to make a suggestion on that topic:
I don't know whether it's right or wrong to interprete \' as ' or really
\'. I would entirely leave this decision up to you. But: To change to a
root folder on Windows if one uses the "Select Folder" dialog is not
working. In my opinion this clearly IS a bug.
So my suggestion is as follows: Why not intercepting at least the return
value of the "Select Folder" dialog to provide the "cd" command with a
valid path. This bug seems to apply only to root folders that have a
trailing backslash. Other folders the "Select Folder" dialog returns
without the backslash at the end. So it's a simple:
if ("2 letters on the right of the path" == ":\") then
(replace "\" with "\\") modification.
Thus the "cd" command becomes cd 'D:\\', which works.
I assume that this would always be right and it doesn't matter than how
the qutotation are handled. A \\ should always be interpreted as a \ so
this replacement is correct.
With regards,
Martin Halle.
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-21 11:51:43
|
Martin Halle wrote: > I don't know whether it's right or wrong to interprete \' as ' or really > \'. It's neither --- because that's not what's actually happening. You can tell by observing that \' in a single-quoted string is interpreted as a ' only if it's the end of the string (and the command line). There are problem with the parsing of '' strings, but backslash quoting is not one of them. > would entirely leave this decision up to you. But: To change to a > root folder on Windows if one uses the "Select Folder" dialog is not > working. It works if you think a bit less Windows-ish. Write c:/ instead of c:\, or cd 'c:/' directly in the command line, and everything just works. > So my suggestion is as follows: Why not intercepting at least the return > value of the "Select Folder" dialog to provide the "cd" command with a > valid path. Because that's the wrong place to fix it. |
|
From: Martin H. <mar...@gm...> - 2005-11-21 14:17:39
|
Hans-Bernhard Broeker wrote: > It's neither --- because that's not what's actually happening. [...] > You can tell by observing that \' in a single-quoted string > is interpreted as a ' only if it's the end of the string [...] Ok, thanks for correcting me - I obviously had misunderstood. > It works if you think a bit less Windows-ish. Write c:/ > instead of c:\, or cd 'c:/' [...] Agreed. Please allow me to bug you again with my second post: There I mentioned to to intercept the return value of Win32 dialogs (such as "Folder Select", "Open File"...) and replace all backslashes there with forward slashes. Correct me, if I'm wrong but I believe the dialogs always return backslashed path's. Thus the path would be compatible with what you said above in the first place. So maybe such conversion under Windows make things easier - I mean, generally... (not pushing anything here)?! Of course the parsing issue remains. I am aware that fixing this would automatically fix the problem from above... but eventually it helps on second thoughts...?! .....and if there is a reason not to do so then I would also be intereseted in. Thanks. With regards, Martin Halle. |
|
From: Martin H. <mar...@gm...> - 2005-11-19 15:18:19
|
Dear all, just right after sending my last post another idea came into my mind: Wouldn't it be valid in general to replace a single "\" with a double "\\" in a path (the "Select Folder" dialog returns)? So e.g. 'D:\' would become 'D:\\' and e.g. 'C:\MyDir\MyOtherDir' would become 'C:\\MyDir\\MyOtherDir'. This would make the replacement a lot easier (just replace all single backslashes with double ones), is valid and works (I've just tried it). It would be even compatible to *nix since there no backslash appears in a path (or does it?). Thus the replacement would replace "nothing"... ;-) Maybe it's worth considering this...?! What do you think? With regards, Martin Halle |
|
From: Petr M. <mi...@ph...> - 2005-11-23 23:36:00
|
> just right after sending my last post another idea came into my mind: > Wouldn't it be valid in general to replace a single "\" with a double > "\\" in a path (the "Select Folder" dialog returns)? > So e.g. 'D:\' would become 'D:\\' and e.g. 'C:\MyDir\MyOtherDir' would > become 'C:\\MyDir\\MyOtherDir'. This would make the replacement a lot > easier (just replace all single backslashes with double ones), is valid > and works (I've just tried it). > > It would be even compatible to *nix since there no backslash appears in > a path (or does it?). Thus the replacement would replace "nothing"... ;-) > > Maybe it's worth considering this...?! What do you think? If it is a bug, and you have figured out the solution as indicated above, please send us an appropriate patch. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 16:50:16
|
On Sunday 13 November 2005 06:27 am, Petr Mikulik wrote:
>
> It is a bug.
>
> Can be reproduced in this way:
>
> gnuplot> set title 'c:\'
> gnuplot> show title
>
> title is "c:\\'", offset at ((character units) 0, 0, 0)
> It seems routine try_to_get_string() returns one superfluous ' more.
It has nothing to do with try_to_get_string().
The behaviour has been there since at least version 3.7
Backslash is an escape character, and you have escaped the trailing
single quote. This forces it to be kept in the string.
What you need to do is to escape the backslash itself,
and use double quotes:
gnuplot> set title "c:\\"
gnuplot> show title
title is "c:\\", offset at ((character units) 0, 0, 0)
This time the first backslash is an escape for the second backslash.
When you use the title in a plot, you will get only one backslash printed.
Now, whether this has anything to do with windows command lines, I'm
not so sure.
Does the original problem persist if you use double quotes?
Can you use the cygwin syntax (forward slash) instead?
cd "c:/"
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2005-11-13 19:04:41
|
>> Can be reproduced in this way:
>>
>> gnuplot> set title 'c:\'
>> gnuplot> show title
>>
>> title is "c:\\'", offset at ((character units) 0, 0, 0)
>> It seems routine try_to_get_string() returns one superfluous ' more.
>
> It has nothing to do with try_to_get_string().
> The behaviour has been there since at least version 3.7
> Backslash is an escape character, and you have escaped the trailing
> single quote. This forces it to be kept in the string.
> What you need to do is to escape the backslash itself,
> and use double quotes:
\ is an escape character in quotes " only, not in '
See:
gnuplot> set title 'c:\tmp'
gnuplot> show title
title is "c:\\tmp", offset at ((character units) 0, 0, 0)
gnuplot> set title 'c:\'
gnuplot> show title
title is "c:\\'", offset at ((character units) 0, 0, 0)
In the bug report example, gnuplot mistakenly adds an '
> Does the original problem persist if you use double quotes?
> Can you use the cygwin syntax (forward slash) instead?
> cd "c:/"
This works.
---
PM
|
|
From: Martin H. <mar...@gm...> - 2005-11-13 19:22:22
|
>> Can you use the cygwin syntax (forward slash) instead? >> cd "c:/" > > This works. I can confirm this. Hence the "Change Folder" dialog (from the Windows GUI menu) will not provide this. I assume that Windows users will stick with the dialog instead of typing into the Gnuplot console... (as I do ;-). I am just writing this to keep it in mind when searching for a solution... With best regards, Martin. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 19:49:51
|
Nevertheless, so far as I can tell from testing, versions 3.7, 4.0, and 4.1 all behave the same way. Why is it suddenly a bug now, but not for the past 10 years? On Sunday 13 November 2005 11:04 am, Petr Mikulik wrote: > >> Can be reproduced in this way: > >> > >> gnuplot> set title 'c:\' > >> gnuplot> show title > >> > >> title is "c:\\'", offset at ((character units) 0, 0, 0) > >> It seems routine try_to_get_string() returns one superfluous ' > >> more. > > > > It has nothing to do with try_to_get_string(). > > The behaviour has been there since at least version 3.7 > > Backslash is an escape character, and you have escaped the trailing > > single quote. This forces it to be kept in the string. > > What you need to do is to escape the backslash itself, > > and use double quotes: > > \ is an escape character in quotes " only, not in ' > > See: > > gnuplot> set title 'c:\tmp' > gnuplot> show title > > title is "c:\\tmp", offset at ((character units) 0, 0, 0) > > gnuplot> set title 'c:\' > gnuplot> show title > > title is "c:\\'", offset at ((character units) 0, 0, 0) > > > In the bug report example, gnuplot mistakenly adds an ' > > > Does the original problem persist if you use double quotes? > > > > Can you use the cygwin syntax (forward slash) instead? > > cd "c:/" > > This works. > > --- > PM -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2005-11-13 20:17:42
|
> Nevertheless, so far as I can tell from testing, versions > 3.7, 4.0, and 4.1 all behave the same way. > Why is it suddenly a bug now, but not for the past 10 years? It was always a bug, but nobody noticed. --- PM |
|
From: Juergen W. <wie...@fr...> - 2005-11-13 20:58:31
|
On Sunday 13 November 2005 21:17 Petr Mikulik wrote: > > Nevertheless, so far as I can tell from testing, versions > > 3.7, 4.0, and 4.1 all behave the same way. > > Why is it suddenly a bug now, but not for the past 10 years? > > It was always a bug, but nobody noticed. I thought so, too, when I first noticed this behaviour two months ago. But then, why is it a bug? Where do the docs say what backslashes do in single quoted strings? The current single quoted strings work very much the same way as "raw strings" do in python. Nevertheless, it seems counterintuitive to me. It should at least be documented. As a side note: If the current behaviour is changed, patch [1289725] "handling double quotes in gnuplot-mode" will be outdated (and I wouldn't know how to fix it). Juergen |
|
From: Petr M. <mi...@ph...> - 2005-11-13 21:01:37
|
>>> Nevertheless, so far as I can tell from testing, versions >>> 3.7, 4.0, and 4.1 all behave the same way. >>> Why is it suddenly a bug now, but not for the past 10 years? >> >> It was always a bug, but nobody noticed. > > I thought so, too, when I first noticed this behaviour two months > ago. But then, why is it a bug? Where do the docs say what > backslashes do in single quoted strings? The current single quoted > strings work very much the same way as "raw strings" do in python. > Nevertheless, it seems counterintuitive to me. It should at least > be documented. > > As a side note: If the current behaviour is changed, patch [1289725] > "handling double quotes in gnuplot-mode" will be outdated (and I > wouldn't know how to fix it). There is no change to behaviour: this works: X 'C:\tmp' this not: X 'C:\' where X is set title or cd or whatever else. --- PM |
|
From: Juergen W. <wie...@fr...> - 2005-11-13 21:22:26
|
On Sunday 13 November 2005 22:01 Petr Mikulik wrote: > > As a side note: If the current behaviour is changed, patch [1289725] > > "handling double quotes in gnuplot-mode" will be outdated (and I > > wouldn't know how to fix it). > > There is no change to behaviour: > this works: X 'C:\tmp' > this not: X 'C:\' > where X is set title or cd or whatever else. I simply don't understand you (which may be the case because you haven't understood me, so: more probably my fault). What do you mean by "works"? Raw strings in python and single quoted strings in gnuplot are *very* special. In your second example, the first single quote starts the string, then there are two ordinary characters. Then there is an *odd* number of backslashes, meaning that the following character is to be taken literally *as are all of the backslashes*. The string is ended implicitly by the end of the line. So, there is no bug. Just a very silly syntax. I don't know who has invented this and why, but gnuplot is not the only program using it. The main problem seems to be that gnuplot silently ends a string at the end of a line without even giving a warning. And if you do change the latter example to work the way you expect, the named patch will be broken. Juergen |
|
From: Petr M. <mi...@ph...> - 2005-11-13 21:32:12
|
>> There is no change to behaviour:
>> this works: X 'C:\tmp'
>> this not: X 'C:\'
>> where X is set title or cd or whatever else.
>
> I simply don't understand you (which may be the case because you
> haven't understood me, so: more probably my fault). What do you
> mean by "works"?
gnuplot> set title 'C:\tmp'; show title
title is "C:\\tmp", offset at ((character units) 0, 0, 0)
gnuplot> set title 'C:\'; show title
gnuplot> set title 'C:\'
gnuplot> show title
title is "C:\\'", offset at ((character units) 0, 0, 0)
gnuplot>
So it looks there are two bugs:
1. A problem with c_token++ (?) on the 2nd line (prompt)
2. On the 3rd line, it should be "C:\\" and not "C:\\'"
> starts the string, then there are two ordinary characters. Then
> there is an *odd* number of backslashes, meaning that the following
> character is to be taken literally *as are all of the backslashes*.
> The string is ended implicitly by the end of the line. So, there is
> no bug. Just a very silly syntax. I don't know who has invented
> this and why, but gnuplot is not the only program using it.
In gnuplot, the \ is escape character in "this" string, but a normal
character in 'this' string.
---
PM
|
|
From: Juergen W. <wie...@fr...> - 2005-11-13 21:43:56
|
On Sunday 13 November 2005 22:31 Petr Mikulik wrote:
> gnuplot> set title 'C:\tmp'; show title
>
> title is "C:\\tmp", offset at ((character units) 0, 0, 0)
>
> gnuplot> set title 'C:\'; show title
> gnuplot> set title 'C:\'
> gnuplot> show title
>
> title is "C:\\'", offset at ((character units) 0, 0, 0)
>
> gnuplot>
gnuplot> set title 'C:\'; show title
gnuplot> show title
title is "C:\\'; show title", offset at ((character units) 0, 0, 0)
gnuplot>
As I said: The string is implicitly ended by the end of the line,
not by the last single quote.
> In gnuplot, the \ is escape character in "this" string, but a normal
> character in 'this' string.
I would have expected this, too, two months ago. But which section
of the docs says so? I haven't found any. If I had, I would have
submitted a bug report, then. I say, it's not a bug, it's weird
undocumented behaviour (which may end up being mostly the same).
But there *is* an example of a similar syntax out there (raw
strings). So there probably is a reason for it.
Don't get me wrong: I don't promote the current syntax. Change it
if you like. I just want to explain it.
Juergen
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-13 22:06:34
|
On Sunday 13 November 2005 01:44 pm, Juergen Wieferink wrote:
> gnuplot> set title 'C:\'; show title
> gnuplot> show title
>
> title is "C:\\'; show title", offset at ((character units) 0, 0, 0)
>
> gnuplot>
>
> As I said: The string is implicitly ended by the end of the line,
> not by the last single quote.
Not quite right.
It *would* be ended by the trailing single quote, if there were one.
But there is no such trailing single quote in your command line
because the only candidate has been escaped by a backslash.
gnuplot> set title 'C:\'; foo' ; show title
title is "C:\\'; foo", offset at ((character units) 0, 0, 0)
The backslash character is always interpreted as an escape during input.
Single or double quotes make no difference.
I agree with Juergen that it may not be the most intuitive syntax,
but gnuplot is not the only program to behave this way.
I also agree that it might be more intuitive to have the lack of
a trailing quote be reported as an error, rather than being silently
"corrected" by adding an implicit extra character.
That still wouldn't make the original example work, but at least
you might get some hint as to what went wrong. Something like:
gnuplot> cd 'C:\'
^
Error: No trailing quote found for string constant.
>
> > In gnuplot, the \ is escape character in "this" string, but a normal
> > character in 'this' string.
>
> I would have expected this, too, two months ago. But which section
> of the docs says so? I haven't found any. If I had, I would have
> submitted a bug report, then. I say, it's not a bug, it's weird
> undocumented behaviour (which may end up being mostly the same).
> But there *is* an example of a similar syntax out there (raw
> strings). So there probably is a reason for it.
>
> Don't get me wrong: I don't promote the current syntax. Change it
> if you like. I just want to explain it.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-14 08:45:17
|
Ethan A Merritt wrote:
> It *would* be ended by the trailing single quote, if there were one.
> But there is no such trailing single quote in your command line
> because the only candidate has been escaped by a backslash.
No, it's not supposed to be escaped. At least not in any version up to
4.0 it wasn't. There are no backslash escapes being processed on
single-quoted strings in gnuplot, period. See 'help syntax'. Thus this
behaviour:
> gnuplot> set title 'C:\'; foo' ; show title
> title is "C:\\'; foo", offset at ((character units) 0, 0, 0)
Is a bug, and has been as long as it was present in the program.
> The backslash character is always interpreted as an escape during input.
Not inside single-quoted strings.
> Single or double quotes make no difference.
If so, that's a bug, or an incompatible change since version 4.0. Proof
from 4.0 on Win32:
gnuplot> set label 1 "a\n\t\\\qb"
gnuplot> set label 2 'a\n\t\\\qb'
gnuplot> show lab
label 1 "a\n\t\\qb" at (0, 0, 0) left not rotated back nopoint
label 2 "a\\n\\t\\\\\\qb" at (0, 0, 0) left not rotated back nopoint
gnuplot>
In other words: \-escape sequences in "" can become special characters
like LF, TAB or the backslash itself, whereas \ characters in '' become
literal \ characters, which 'show' doubles up since it uses "" strings.
|
|
From: Petr M. <mi...@ph...> - 2005-11-14 16:33:33
|
> No, it's not supposed to be escaped. At least not in any version up to 4.0 > it wasn't. There are no backslash escapes being processed on single-quoted > strings in gnuplot, period. See 'help syntax'. Thus this > behaviour: > >> gnuplot> set title 'C:\'; foo' ; show title >> title is "C:\\'; foo", offset at ((character units) 0, 0, 0) > > Is a bug, and has been as long as it was present in the program. > > In other words: \-escape sequences in "" can become special characters like > LF, TAB or the backslash itself, whereas \ characters in '' become literal \ > characters, which 'show' doubles up since it uses "" strings. > > Not inside single-quoted strings. Exactly. Thus, 'C:\tmp' is really C:\tmp and not C:<TAB>tmp, and '\' is really \ (1 char) and not anything else. --- PM |
|
From: Juergen W. <wie...@fr...> - 2005-11-14 17:45:25
|
On Monday 14 November 2005 17:33 Petr Mikulik wrote: > Exactly. Thus, 'C:\tmp' is really C:\tmp and not C:<TAB>tmp, and '\' is > really \ (1 char) and not anything else. Let's agree on "should be". Obviously, it *is* not so far. ;-) Juergen |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-14 18:35:02
|
On Monday 14 November 2005 08:33 am, Petr Mikulik wrote: > > Exactly. Thus, 'C:\tmp' is really C:\tmp and not C:<TAB>tmp, and '\' is > really \ (1 char) and not anything else. The two cases are not parallel. \t is a "special character" that is expanded to <tab> in double quotes but not in single quotes. \' or \" are not "special characters", they are escaped quotes. If you do not allow some mechanism for escaping quotes, then you cannot represent a quote inside a quoted string. gnuplot> a = "foo\"bar" gnuplot> print a foo"bar gnuplot> b = 'foo\'bar' gnuplot> print b foo\'bar If there is a bug here, it is not the fact that the backslash escapes the single-quote. It is that the print routine should know enough not to _print_ the backslash in such a case. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-15 11:24:06
|
Ethan Merritt wrote: > \' or \" are not "special characters", they are escaped quotes. > If you do not allow some mechanism for escaping quotes, then you > cannot represent a quote inside a quoted string. The mechanism for escaping quotes in gnuplot is to use a double-quoted string and use backslash escapes. There is neither a need for supporting backslash escapes in single-quoted strings, nor does the documentation even suggest such a thing, anywhere. > gnuplot> a = "foo\"bar" > gnuplot> print a > foo"bar > > gnuplot> b = 'foo\'bar' > gnuplot> print b > foo\'bar > > If there is a bug here, it is not the fact that the backslash > escapes the single-quote. It is that the print routine should > know enough not to _print_ the backslash in such a case. No, the bug is that the command b = 'foo\'bar' was accepted in the first place. It should have flagged a syntax error. |
|
From: Petr M. <mi...@ph...> - 2005-11-15 13:43:30
|
>> If you do not allow some mechanism for escaping quotes, then you >> cannot represent a quote inside a quoted string. > > The mechanism for escaping quotes in gnuplot is to use a double-quoted string > and use backslash escapes. There is neither a need for supporting backslash > escapes in single-quoted strings, nor does the documentation even suggest > such a thing, anywhere. > > No, the bug is that the command > > b = 'foo\'bar' > > was accepted in the first place. It should have flagged a syntax error. Consequently, we have two possibilities: 1. \ is always \ in 'strings'; however, there is no possibility to type in a quote ' This helps writing e.g. 'cd C:\tmp\' 2. there is only one escape possibility inside 'string': \' means ' Currently, gnuplot uses option 2. but docs tends to 1, so it is an open question what to fix. If people say escape \' is usual in other languages, I would vote for 2. Then, docs should include an explicit help for 'cd c:/tmp/' for Windows users. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-15 14:36:48
|
Petr Mikulik wrote:
> 1. \ is always \ in 'strings'; however, there is no possibility to type
> in a quote '
> This helps writing e.g. 'cd C:\tmp\'
>
> 2. there is only one escape possibility inside 'string': \' means '
>
> Currently, gnuplot uses option 2.
No, it didn't. If it does now, that's an incompatible change. Viz
version 4.0 behaviour:
gnuplot> set label 1 'c:\'\win98'
gnuplot> show lab
label 1 "c:\\'\\win98" at (0, 0, 0) left not rotated back nopoint
I.e. as of version 4.0, the status actually was that \' is *not* an
escape --- both the \ and the ' made it into the string unmodified.
The actual bug in 4.0 only happens if \' is at the end of the command.
It's a side effect of the auto-closing of strings. The convenience
feature helper that allows people to type
set label 1 'foo
and makes that mean the same thing as
set label 1 'foo'
mistakenly transforms
set label 1 'foo\'
into
set label 1 'foo\''
|
