Home > Archive > Fortran > February 2008 > Fortran 2008 draft: EXECUTE_COMMAND_LINE
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fortran 2008 draft: EXECUTE_COMMAND_LINE
|
|
|
| I'm reading the description of EXECUTE_COMMAND_LINE in the current
Fortran 2008 draft. I have questions about the following:
-- "WAIT (optional) shall be a default character scalar. It is an
INTENT (IN) argument. If WAIT is present with the value false, [...]".
Will WAIT really by a character expression? What advantages does it have
over a logical scalar?
-- "EXITSTAT (optional) shall be a default character scalar. It is an
INTENT (INOUT) argument. If the command is executed synchronously, it is
assigned the value of the processor-dependent exit status." Again,
shouldn't that be an integer scalar? Most exit status are integers (see
the STOP intrinsic, for example).
-- "CMDSTAT (optional) shall be a default character scalar. It is an
INTENT (OUT) argument. It is assigned the value −1 [...]" I suspect that
this should be an integer also... unless you want to assign the character
value '-1', but it wouldn't make much sense to me!
-- "CMDMSG (optional) shall be a default character scalar. It is an
INTENT (INOUT) argument. If an error condition occurs, it is assigned a
processor-dependent explanatory message." I don't suppose there's any way
I can convince anyone that CMDMSG should be an integer or logical scalar.
--
FX
| |
| Dan Nagle 2008-02-29, 8:23 am |
| Hello,
On 2008-02-29 05:46:15 -0500, "FX" <coudert@alussinan.org> said:
> I'm reading the description of EXECUTE_COMMAND_LINE in the current
> Fortran 2008 draft. I have questions about the following:
>
> -- "WAIT (optional) shall be a default character scalar. It is an
> INTENT (IN) argument. If WAIT is present with the value false, [...]".
> Will WAIT really by a character expression? What advantages does it have
> over a logical scalar?
It's a typo, it should read scalar logical.
>
> -- "EXITSTAT (optional) shall be a default character scalar. It is an
> INTENT (INOUT) argument. If the command is executed synchronously, it is
> assigned the value of the processor-dependent exit status." Again,
> shouldn't that be an integer scalar? Most exit status are integers (see
> the STOP intrinsic, for example).
It's a typo, it should read scalar integer.
>
> -- "CMDSTAT (optional) shall be a default character scalar. It is an
> INTENT (OUT) argument. It is assigned the value −1 [...]" I suspect that
> this should be an integer also... unless you want to assign the character
> value '-1', but it wouldn't make much sense to me!
It's a typo, it should read scalar integer.
>
> -- "CMDMSG (optional) shall be a default character scalar. It is an
> INTENT (INOUT) argument. If an error condition occurs, it is assigned a
> processor-dependent explanatory message." I don't suppose there's any way
> I can convince anyone that CMDMSG should be an integer or logical scalar.
All the *msg arguments are character, they're the processor's
error message.
HTH
--
Cheers!
Dan Nagle
| |
|
| Thanks for the comments. Should I forward that to the working group in
one way or another, or can I consider it taken care of?
>
> All the *msg arguments are character, they're the processor's error
> message.
Yep, that was a lame try at making a joke. I should know better than
trying in a language that's not my mother tongue.
--
FX
| |
| Dan Nagle 2008-02-29, 7:17 pm |
| Hi,
On 2008-02-29 09:28:03 -0500, "FX" <coudert@alussinan.org> said:
> Thanks for the comments. Should I forward that to the working group in
> one way or another, or can I consider it taken care of?
>
>
> Yep, that was a lame try at making a joke. I should know better than
> trying in a language that's not my mother tongue.
No problem. Just use a ;-) so I can hear the tone of voice. ;-)
--
Cheers!
Dan Nagle
| |
| GaryScott 2008-02-29, 7:17 pm |
| On Feb 29, 8:51=A0am, Dan Nagle <danna...@verizon.net> wrote:
> Hi,
>
> On 2008-02-29 09:28:03 -0500, "FX" <coud...@alussinan.org> said:
>
>
>
>
>
> No problem. =A0Just use a ;-) so I can hear the tone of voice. =A0;-)
>
> --
> Cheers!
>
> Dan Nagle
Was there any discussion of including a "silent" option to suppress
the appearance of that annoying console window on Windows? It is
possible to suppress it, but the typical "system" procedures don't
suppress it, regardless of whether anything is written to the screen
or not (SW_HIDE, show window_hide).
| |
| Harold Stevens 2008-02-29, 7:17 pm |
| In <fq94pj$2qmb$1@nef.ens.fr> FX:
[Snip..]
> Yep, that was a lame try at making a joke.
Here, let me help... :)
<LameJoke>
ALL YOUR ARGUMENT ARE BELONG TO US!
</LameJoke>
:)
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.
| |
| Dan Nagle 2008-02-29, 7:17 pm |
| Hello,
Please trim the requoted stuff from your post!
On 2008-02-29 10:46:56 -0500, GaryScott <garylscott@sbcglobal.net> said:
>
> Was there any discussion of including a "silent" option to suppress
> the appearance of that annoying console window on Windows? It is
> possible to suppress it, but the typical "system" procedures don't
> suppress it, regardless of whether anything is written to the screen
> or not (SW_HIDE, show window_hide).
No, whether a console window, DOS-box, etc, adn, appears
is highly processor-dependent. The discussion goes out of its way
to say that it doesn't even discuss whether a shell interprets
the command, or what it means to execute it "raw", or what a path is,
or anything else along these lines.
Sorry, but the standard simply doesn't go into that level of detail
about how programs are executed (or how they exit).
(Read the weasel-words about what stop does.)
There was some concern whether execute_command_line()
would be of any value anyway, since the command itself is
processor dependent.
I wrote the original paper (05-240r4), in response to repeated requests,
here and elsewhere, for a standard "execcl" functionality.
I was finally able to get agreement that, while not a cure-all,
such an intrinsic would help. That is all. (BTW, note the "r4"
in the paper number. That's how hard it was to get this right,
with all the processor dependencies involved!)
--
Cheers!
Dan Nagle
|
|
|
|
|