next »

[.]

Hi

Is there a function that returns the operation system the DVM is running on ? The documentation has an example  that uses fgl_getenv("OS") and gets the value from an environment variable. Now this is something the user can set and ideally an inbuilt function is what we want to use.

kind regards
Bothwell

[Sebastien F.]

We do not plan to implement such function...

Usually, in our regression tests, when we have to detect the OS type, it's because of UNIX/Windows differences, and we do that with:

Code

    IF fgl_getenv("WINDIR") THEN
        -- Windows specific
    ELSE
        -- UNIX specific
    END IF
 

Seb

[Reuben B.]

Hi

Is there a function that returns the operation system the DVM is running on ? The documentation has an example  that uses fgl_getenv("OS") and gets the value from an environment variable. Now this is something the user can set and ideally an inbuilt function is what we want to use.

kind regards
Bothwell

you could argue that https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Ext_os_Path.html#FILE_SEPARATOR is inbuilt.  I wonder if there is a method in there we could expose.

[Sebastien F.]

Bothwell,

May I ask why you need to know what operating system you run on?
There must certainly be a good reason, but I first want to check if it's possible to write portable code.
This is why we introduced utility functions like os.Path.separator() and os.Path.pathseparator() ...

Seb

[.]

Hi

The reason  is that we were merging our Linux (live application) and Windows (demo application), so that we use the same code but then we detect the OS then disable cetain functionality if the application is a demo running on Windows.

Kind regards
Bothwell

[.]

.... a simple example is when we call a  linux command  like when sending email:

  LET lv_command = "/usr/sbin/sendmail -t < ", lv_email
  run lv_command

this wouldnt work on Windows, and so we obviously needed to detect the operating system before making such a call. We also have some initializing that is done on a live system that would not be neccessary on a stand alone windows laptop

[Reuben B.]

Seb,

If you want other examples of where Genero code has to take the operating system into account.

Operationally the big one that springs to mind is the printing of files, lp versus print.  We always did START REPORT TO FILE and did a lp or print for immediate printing or later reprints.  Faxing also typically had its own command depending upon the OS.

For debugging purposes if you ever want to get the list of environment variables to check that everything is set up correctly, it is env versus set.  We also had something like strings *.42m | grep "$Id" to get the CVS version that we had embedded in the .42m, this was available at run-time for support to check they had the write version of each module, we had no equivalent under a windows system.

I suppose you could argue, do you code as

CASE get_os()
   WHEN "*NIX" LET command = "env"
   WHEN "WINDOWS" LET command = "set"
END CASE

or do you have portable code but with a little bit of setup outside your application...

LET command = read_from_configuration_file("OS_COMMAND_TO_LIST_ENVIRONMENT_VARIABLES")
LET command = FGL_GETENV("OS_COMMAND_TO_LIST_ENVIRONMENT_VARIABLES")
LET command = "python_script_to_list_environment_variables.py"

or do you use the Java Interface if there is an appropriate Java method out there.

Reuben

[Sebastien F.]

Yes I understand there are cases where you need to identity the OS.
No discussion.

But I don't think we should provide a built-in function for that.

As I suggested before you can detect the WINDOWS/UNIX different with:

   IF fgl_getenv("WINDIR") IS NOT NULL THEN
      RETURN "WINDOWS"
   ELSE
     RETURN "UNIX"
   END IF

You can also check for more detailed OS info with other env vars like OS on Windows and running the uname command on UNIX.

This can become very specific so we better let this is the hand of programmers.

I believe there are other (more important) features we should talk about.

Seb