Prev: Not consistent unformatted write
Next: order statistics of the Normal distribution
From: dpb on 5 Mar 2010 10:10
baf wrote:
> On 3/4/2010 10:27 PM, qquito wrote:
>> On Mar 4, 11:47 pm, nos...(a)see.signature (Richard Maine) wrote:
>>> qquito<qqu...(a)hotmail.com> wrote:
>>>> I have used the INQUIRE statement in Fortran 90 to determine if a file
>>>> with a given name exists or not. Now I need to determine if a
>>>> DIRECTORY is empty or not. Can I use the INQUIRE to do the job? And
>>>> how? If not, is there any other function in Fortran 90 that can do the
>>>> job?
>>>
>>> The Fortran language does not even have the concept of a directory. So
>>> you need something system specific. As Sjouke suggests, one such system
>>> specific way would be to capture the output of an appropriate shell
>>> command (though note that the SYSTEM subroutine that he mentions is also
>>> nonstandard, though things like it are reasonably common extensions).
>>
>> Thank you, Richard and Sjouke, for your replies!
>>
>> I use a Mac OS X machine under a Bash Shell, and I have found a
>> command
>>
>> % ["$(ls -A Mydirectory)"]&& echo "1" || echo "0"
>>
>> If Mydirectory is empty, I get 0; if not, I get 1. And I can use "call
>> system()" to execute the above.
>>
>> But the question is: How can I capture the output of either 0 or 1
>> from the above with a variable defined by me in my Fortran 90 code?
>>
>> --Roland
>
> Redirect the output to a file
>
> % ["$(ls -A Mydirectory)"]&& echo "1" || echo "0" > directory_status
>
> Then open and read the file with Fortran

Or see if your compiler supports returning the exit code w/ a SYSTEM()
function call (or whatever is the implemented variant name for the
functionality, assuming there is one).

--
From: Richard Maine on 5 Mar 2010 11:15
dpb <none(a)non.net> wrote:

> Or see if your compiler supports returning the exit code w/ a SYSTEM()
> function call (or whatever is the implemented variant name for the
> functionality, assuming there is one).

But be aware that most don't. That is the source of a reasonably comon
confusion. Some variants do return an error code, but the error code
usually indicates whether or not the shell command was successfully
spawned rather than what error code the command returned.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 5 Mar 2010 13:30
Richard Maine <nospam(a)see.signature> wrote:
> dpb <none(a)non.net> wrote:

>> Or see if your compiler supports returning the exit code w/ a SYSTEM()
>> function call (or whatever is the implemented variant name for the
>> functionality, assuming there is one).

> But be aware that most don't. That is the source of a reasonably comon
> confusion. Some variants do return an error code, but the error code
> usually indicates whether or not the shell command was successfully
> spawned rather than what error code the command returned.

C/unix derived system() does return the exit code, or the error
return from the spawn. In my test on a Linux system:

#include <stdio.h>
int main() {
printf("%d\n",system("ls | grep ."));
}

prints 256 if the directory didn't exist, and 0 if it did.
I didn't track down if that made sense in terms of return
codes, but that is what it did. The return code from grep is
0 if items were found, and 1 if they were not. There might be
easier ways to get the results out of ls.

You might be able to run the C system() through C interoperability
if the Fortran version does not supply a return code.

-- glen
From: dpb on 5 Mar 2010 14:52
Richard Maine wrote:
> dpb <none(a)non.net> wrote:
>
>> Or see if your compiler supports returning the exit code w/ a SYSTEM()
>> function call (or whatever is the implemented variant name for the
>> functionality, assuming there is one).
>
> But be aware that most don't. That is the source of a reasonably comon
> confusion. Some variants do return an error code, but the error code
> usually indicates whether or not the shell command was successfully
> spawned rather than what error code the command returned.

As in all things compiler/vendor-dependent one's expectations depend on
the compiler(s) one is used to...in my case, the desired result (from
the command executed by the shell, not just the shell exit code) is the
behavior for at least most things I've tried. I'm prepared to find that
some commands may not have that behavior even w/ this particular
compiler or that other compilers/OS combinations don't have nirvana for
any command (unless there's some underlying OS reason that makes such an
implementation very difficult I fail to see much (as in any) logic in
that vendor choice but it's an extension so all caveats apply, of course).

In general, obviously one would have to investigate the implementation
for any particular compiler/system .

--
From: dpb on 5 Mar 2010 18:19
dpb wrote:
....
> As in all things compiler/vendor-dependent one's expectations depend on
> the compiler(s) one is used to...in my case, the desired result (from
> the command executed by the shell, not just the shell exit code) is the
> behavior for at least most things I've tried. I'm prepared to find that
> some commands may not have that behavior even w/ this particular
> compiler ...

Actually, I looked at the documentation and there's another routine as
well as SYSTEM() w/ this compiler that returns a LOGICAL that is
documented to be the shell success. I hadn't realized the difference in
the two variants previously.

--
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Not consistent unformatted write
Next: order statistics of the Normal distribution