Add filesystem interaction

[minhqdao]

This PR introduces filesystem interactions by pragmatically invoking the system shell. It is part of the broader strategy outlined in #865 (see #865 (review)) to support file zipping and unzipping. These functionalities are essential for handling .npz files.

[zoziha]

Thanks for this work, @minhqdao. Looking forward to the Stdlib starting to integrate filesystem-related routines. This is the beginning of a new category. In addition to the two noted issues, the function interfaces introduced by this PR should be documented in the specifications later.

(see also fpm::filesystem)

[zoziha]

Note that under Windows OS, mkdir temp will create a temp folder under the current path pwd. Is this appropriate?

[minhqdao]

It is a very pragmatic solution, but I think it should be fine for now

[perazz]

I believe an option to redirect the command output (stdout, stderr) to a string variable would be very useful. It is being done in the fpm version of this function already.

[minhqdao]

I think it slightly exceeds the scope of this PR but it can easily be done in a follow-up PR

[arjenmarkus]

Windows has NO command "rm", I just confirmed that. You need "del" instead and quite possibly "del /q" to make sure no questions aer asked. To get a clean listing of all the files in a directory, use "dir /b". A side note: many commands on Windows do accept the forward slash as well as the backward slash to indicate directories. Although, you can get strange surprises. Where "cd" accepts the forward slash, "dir" does not. Oh well, best stick with the backslash ;). Op do 19 sep 2024 om 08:22 schreef Federico Perini ***@***.***

…

: ***@***.**** commented on this pull request. ------------------------------ In src/stdlib_io_filesystem.f90 <#874 (comment)>: > + + integer :: unit, stat + character(len=256) :: line + + stat = 0 + + if (.not. exists(temp_dir)) then + call run('mkdir '//temp_dir, stat) + if (stat /= 0) then + if (present(iostat)) iostat = stat + if (present(iomsg)) iomsg = "Failed to create temporary directory '"//temp_dir//"'." + return + end if + end if + + call run('ls '//dir//' > '//listed_contents, stat) On the same line as @zoziha <https://github.com/zoziha>, ls may not work under MS Windows unless you are in a WSL environment. There, it would be worth wrapping a call to dir. ------------------------------ In src/stdlib_io_filesystem.f90 <#874 (comment)>: > + end if + + allocate(files(0)) + do + read(unit, '(A)', iostat=stat) line + if (stat /= 0) exit + files = [files, string_type(line)] + end do + close(unit, status="delete") + end + + !> Version: experimental + !> + !> Run a command in the shell. + !> [Specification](../page/specs/stdlib_io.html#run) + subroutine run(command, iostat, iomsg) I believe an option to redirect the command output (stdout, stderr) to a string variable would be very useful. It is being done in the fpm <https://github.com/fortran-lang/fpm/blob/main/src/fpm_filesystem.F90> version of this function already. ------------------------------ In test/io/test_filesystem.f90 <#874 (comment)>: > + subroutine fs_run_valid_command(error) + type(error_type), allocatable, intent(out) :: error + + integer :: stat + + call run("whoami", iostat=stat) + call check(error, stat, "Running a valid command should not fail.") + end + + subroutine fs_list_dir_empty(error) + type(error_type), allocatable, intent(out) :: error + + integer :: stat + type(string_type), allocatable :: files(:) + + call run('rm -rf '//temp_list_dir, iostat=stat) Same as my previous comment, I am not sure if rm is available on non-WSL Windows versions. — Reply to this email directly, view it on GitHub <#874 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR24RFI2GBR2ABYIYW3ZXJURBAVCNFSM6AAAAABOJXKJV6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMJRG42DEMZVGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[minhqdao]

Changes made:

• Activated cpp by using capitalized .F90 suffix.
• Check is_windows during runtime.
• Add platform-agnostic path_separator (/ vs. \).
• Use rmdir \s\q on Windows to remove directories.
• Use dir \b on Windows.
• All tested.
• Add documentation.

@zoziha @jalvesz @arjenmarkus @perazz

[jalvesz]

Hi I went through the PR again and would like to make a few comments.

The first one is purely cosmetic: I think that all procedures should have end function or end subroutine, same for the module. While a standalone end works, it is not a common practice and it felt somehow unnatural. For the sake of coherence with the rest of the library, I would suggest to keep the full closing statement.

The second point: I would like to come back to the preprocessing... I know that it is a sad state of affairs that gfortran does not expose gcc defined macros. Yet, on one hand, I find terribly worrisome to add all those operations just to detirme the OS and then to get the proper path separator. I find it hard to justify all those runtime operations for something that can be a compile-time constant. So I would like to come back to proposing setting the path separator as a simple character(1), parameter, public constant which value is defined by the C preprocessor mechanism. Same for is_windows which can be a logical, parameter, public constant.

This does indeed impose: either relying on CMake, or documenting that one should pass the appropriate definition flags if using plain Makefiles or fpm. This build-time "burden" seems to me more reasonable compared to the runtime operations.

I've opened a discussion to see if fpm could also help improving this preprocessing situation here fortran-lang/fpm#1084

While I find it "tolerable" for fpm having to rely on the runtime implementation as a tool for building, I'm expecting stdlib to be used for more computationally intensive tasks. Thus, it seems to me better to shift the issue to the building documentation and not the library.

[jvdp1]

Thank you @minhqdao for this PR. In addition to all other comments, I think that the proposed features in this PR should have their own modules and specs , and not be related to stdlib_io. what about calling it stdlib_filesystem or even stdlib_os?
See also #201 and this initial project

[minhqdao]

@zoziha @jalvesz @jvdp1

• Runtime checks to determine the OS are eliminated.

But please note for future apis that check OS: When building with CMake, we use CMAKE_SYSTEM_NAME and when building with fpm, we use platform.system() (python). The results might not be the same. It seems to work for OS == "Windows", though.

Further:

• Added end annotations.
• Updated tests.
• Extracted stdlib_filesystem.

However, is_windows is not a filesystem feature but a os one. exists gives information on the filesystem. And run is ... neither (?). I don't want to have too many files as it might end up a bit messy (which is what happened in fpm), so maybe we should just generalize it under stdlib_os? Or stdlib_fs_os? What are your thoughts?