[GRASS-dev] G7: m.proj lacking - as default input answer

Hi,

as per subject, is there a reason that stdin was removed as default
answer for m.proj?
Essentially this would be needed:

Index: scripts/m.proj/m.proj.py

--- scripts/m.proj/m.proj.py (revision 60755)
+++ scripts/m.proj/m.proj.py (working copy)
@@ -36,6 +36,7 @@
#%option G_OPT_F_INPUT
#% label: Name of input coordinate file
#% description: '-' to read from standard input
+#% answer: -
#% required: no
#% guisection: Input coordinates
#%end

but might that cause harm in the wxGUI?

Markus

Hi,

2014-06-10 22:02 GMT+02:00 Markus Neteler <neteler@osgeo.org>:

but might that cause harm in the wxGUI?

right, it was the main reason why all modules (should be) in G7 has
been modified in this way (no default answer for input, stdin requires
`-`).

Martin

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

On Tue, Jun 10, 2014 at 10:04 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2014-06-10 22:02 GMT+02:00 Markus Neteler <neteler@osgeo.org>:

but might that cause harm in the wxGUI?

right, it was the main reason why all modules (should be) in G7 has
been modified in this way (no default answer for input, stdin requires
`-`).

I see. So that's
http://trac.osgeo.org/grass/ticket/2156

I wonder if the could additionally allow for a more human readable
form than input=- like we do for separator=...
"stdin" isn't much better for many users, any other ideas?

Markus

On Tue, Jun 10, 2014 at 4:07 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Jun 10, 2014 at 10:04 PM, Martin Landa <landa.martin@gmail.com>
wrote:
> Hi,
>
> 2014-06-10 22:02 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
>
>> but might that cause harm in the wxGUI?
>
> right, it was the main reason why all modules (should be) in G7 has
> been modified in this way (no default answer for input, stdin requires
> `-`).

I see. So that's
http://trac.osgeo.org/grass/ticket/2156

I wonder if the could additionally allow for a more human readable
form than input=- like we do for separator=...
"stdin" isn't much better for many users, any other ideas?

I don't see a need for more human readable value of input option.

Considering a user-beginner using GUI dialog, "no default answer policy"
saves him or her from running the module and blocking the GUI* as Martin
says.

And advanced user using the real command line probably knows about this
convention and what stdin and standard output are and if not, he or she is
not interested in using input=-.
Option output=- is set by default (or is default implicitly as in r59115,
hopefully everywhere?), so he or she gets standard output which is expected
in both GUI and command line and can set a file if this is what he or she
wants.

* although some clever GUI could parse all commands and refuse file options
set to -
r59115 http://trac.osgeo.org/grass/changeset/59115
#2156 http://trac.osgeo.org/grass/ticket/2156

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Tue, Jun 10, 2014 at 10:29 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Tue, Jun 10, 2014 at 4:07 PM, Markus Neteler <neteler@osgeo.org> wrote:

...

I wonder if the could additionally allow for a more human readable
form than input=- like we do for separator=...
"stdin" isn't much better for many users, any other ideas?

I don't see a need for more human readable value of input option.
Considering a user-beginner using GUI dialog, "no default answer policy"
saves him or her from running the module and blocking the GUI* as Martin
says.

Well, advanced users fail, see this email from some hours ago:
https://lists.fossgis.de/pipermail/fossgis-talk-liste/2014-June/006618.html

(you may guess it from German language)

And advanced user using the real command line probably knows about this
convention and what stdin and standard output are and if not, he or she is
not interested in using input=-.
Option output=- is set by default (or is default implicitly as in r59115,
hopefully everywhere?), so he or she gets standard output which is expected
in both GUI and command line and can set a file if this is what he or she
wants.

The m.proj example in its manual was definitely broken. I have fixed it in
https://trac.osgeo.org/grass/changeset/60783

Markus

On Tue, Jun 10, 2014 at 5:04 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Jun 10, 2014 at 10:29 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
> On Tue, Jun 10, 2014 at 4:07 PM, Markus Neteler <neteler@osgeo.org>
wrote:
...
>> I wonder if the could additionally allow for a more human readable
>> form than input=- like we do for separator=...
>> "stdin" isn't much better for many users, any other ideas?
>>
> I don't see a need for more human readable value of input option.
> Considering a user-beginner using GUI dialog, "no default answer policy"
> saves him or her from running the module and blocking the GUI* as Martin
> says.

Well, advanced users fail, see this email from some hours ago:
https://lists.fossgis.de/pipermail/fossgis-talk-liste/2014-June/006618.html

(you may guess it from German language)

Ach so, Ich verstehe, aber the main problem in this case was the wrong

manual page and also the fact that manual page requires user to understand
unix/linux command line (without explanations or warnings). Former you
fixed, later should be fixed (I'm working on some proposal actually). My
point is that any name you choose will still require user to know what is
standard input and how it is used (e.g. pipe).
I would consider adding synonym if Python compatibility would be a
motivation. In Python, you have for example:

sys.stdin
sys.stdout
sys.stderr

subprocess.PIPE
subprocess.STDOUT

But the usage is a bit different than ours I would say. See Python usage:

p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
p1.stdout.close()
output = p2.communicate()[0]

versus our usage:

r.something rules=PIPE
r.something rules=stdin
r.something rules=-

Wenzel

> And advanced user using the real command line probably knows about this
> convention and what stdin and standard output are and if not, he or she
is
> not interested in using input=-.
> Option output=- is set by default (or is default implicitly as in r59115,
> hopefully everywhere?), so he or she gets standard output which is
expected
> in both GUI and command line and can set a file if this is what he or she
> wants.

The m.proj example in its manual was definitely broken. I have fixed it in
https://trac.osgeo.org/grass/changeset/60783

Markus

Markus Neteler wrote:

>> but might that cause harm in the wxGUI?
>
> right, it was the main reason why all modules (should be) in G7 has
> been modified in this way (no default answer for input, stdin requires
> `-`).

Regardless of this specific issue, the GUI should be fixed so that
stdin isn't inherited (e.g. stdin=PIPE, then p.stdin.close(); or
associate stdin with the null device).

I see. So that's
http://trac.osgeo.org/grass/ticket/2156

I wonder if the could additionally allow for a more human readable
form than input=- like we do for separator=...
"stdin" isn't much better for many users, any other ideas?

I don't see any point. "input=-" probably isn't meaningful from the
GUI. Command-line users will typically be familiar with that syntax.
And unless they're planning on entering data via the terminal, they'll
need to be familiar with the shell's redirection syntax in order to
make use of it.

--
Glynn Clements <glynn@gclements.plus.com>