Sun 15 Jan 2017 03:44:37 PM UTC, comment #10:
I don't think so. When used in the command form, the Octave interpreter will strip off whitespace and everything will work fine. When a user chooses quotes, it's because they want to specifically control how the interpreter will handle the string. In particular, by using single quotes the user is saying that they want to see exactly what they typed with absolutely no interference from Octave (no breaking tokens at spaces, no interpolation of special escape sequences like \n, etc.). If a user has typed
then the interpreter should respect that and assume the programmer has a good reason for requiring a space where it was placed.
|
Sun 15 Jan 2017 03:00:07 AM UTC, comment #9:
OK.
Just a clarification. I was going to suggest applying strtrim(name) to remove any white space first. But it seems that isn't necessary as help() doesn't seem to do such a thing. Should it?
|
Sun 15 Jan 2017 02:25:05 AM UTC, comment #8:
I checked in a cset to specifically look for './' and '.\' and avoid those (http://hg.savannah.gnu.org/hgweb/octave/rev/1b4a16ce14c2).
|
Thu 12 Jan 2017 06:03:18 PM UTC, comment #7:
OH, I see. which() is the part that prints out info at the front of help output:
octave:10> help which
'which' is a function from the file /usr/local/share/octave/4.3.0+/m/help/which.m
OK, so my last comment is maybe more pertinent than I originally thought. If one were to do the following:
It might be better to just stop with
and not print the help for the sin() function. That way it would become immediately clear what went wrong.
But, again, I gave a link to an alternate approach to solving this inattentive-programmer issue that prints a over-shadow warning at the point of the error message which would be far more helpful.
I was going to suggest on the mailing list that the first line of help:
be dropped, but I thought there'd be too much objection. The "which" routine is listed in "help help" see-also, so the user should be able to track down any "duplicate function name in my path" problems at a reasonable rate.
|
Thu 12 Jan 2017 05:40:14 PM UTC, comment #6:
In the case you point out regarding the creation of a variable with the same name as an existing function, it's almost helpful having that little message
'sin' is a variable
because not realizing having done such a thing is very easy to do when concentrating on programming. Here's an example and an approach to addressing that ancillary issue:
https://savannah.gnu.org/bugs/?46852#comment4
|
Thu 12 Jan 2017 04:47:50 PM UTC, comment #5:
Anything which confuses 'which' is going to have this issue. If I define a variable with the same name as a function, then I also get unexpected output. See this session log:
|
Thu 12 Jan 2017 02:56:12 PM UTC, comment #4:
Yep. I see what you're seeing.
Look at help.m at the end
It is the call to evalin which is adding the extra output. I checked and the value of 'text' is correct. You can see this also by using a return argument to help which then takes the else branch above.
|
Thu 12 Jan 2017 07:42:55 AM UTC, comment #3:
That's because "." is always in the path, and both "." and "./" are valid file names which refer to current directory, which is in the load path.
The help function unconditionally calls which(name), which is where that first line comes from. If which(name) prints nothing, then you get nothing, which is what you normally see for all operators. But because which("./") prints that it is the current directory, you get that misleading first line.
Some logic could be added to help.m to see if the given name is an operator and not run which on it.
|
Thu 12 Jan 2017 01:32:42 AM UTC, comment #2:
OK, I see where you are going, but I still see the blurb about the current directory:
I don't see a problem with the given example either.
help +
help "+"
look exactly the same.
This does seem like the source of the issue though.
|
Thu 12 Jan 2017 01:15:36 AM UTC, comment #1:
Try 'help help'
The last sentence in particular was added because all operators need to be enclosed by quotes. If you try
you will get only the correct text.
|
Wed 11 Jan 2017 11:16:22 PM UTC, original submission:
When doing a "help ./" to see the documentation for element-by-element division, something is mistaking that './' for a path to the current directory and prints out a little blurb. There may be some other aspect of "help" pertaining to the contents of scripts in a directory, and maybe this can't be prevented, but it seems strange:
"help .\" is OK, at least on unix, but I'm not sure what would happen in Windows where the backward slash is used for directory specification.
|