Distinguish between osx and linux programmatically

Distinguish between osx and linux programmatically

[Daniel Bünzli]

Hello,

Is there something in the standard library that allows me to
distinguish between oxs and linux (Sys.os_type just returns "Unix" for
both).

Best,

Daniel

Re: [Caml-list] Distinguish between osx and linux programmatically

[Richard Jones]

On Thu, Jul 08, 2010 at 12:02:48PM +0200, Daniel Bünzli wrote:
> Is there something in the standard library that allows me to
> distinguish between oxs and linux (Sys.os_type just returns "Unix" for
> both).

How about running the external "uname" program.  On Mac OS X
it prints:

$ uname 
Darwin

On all Linux distros it prints:

$ uname
Linux

Of course, only run external "uname" if Sys.os_type = "Unix".

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Distinguish between osx and linux programmatically

[Alex]

Hello,

> > Is there something in the standard library that allows me to
> > distinguish between oxs and linux (Sys.os_type just returns "Unix" for
> > both).
we had a similar problem, but finally (ab)used 
   Ocamlbuild_pack.Ocamlbuild_Myocamlbuild_config.system 
and
   Ocamlbuild_pack.Ocamlbuild_Myocamlbuild_config.arch 
in the context of an ocamlbuild script to get
the system and the current architecture (32 vs
64 bit). just adapt to your demands.

it's the same variable that it accessible via the 
"-config" parameter of the ocamltools (ocamlc/ocamlopt/...)
   shell~> ocamlc -config|grep system
please note, that it's not the runtime configuration
but the system configuration at compile time of your
ocaml distribution.

regards,

alex

Re: [Caml-list] Distinguish between osx and linux programmatically

[Daniel Bünzli]

On Thu, Jul 8, 2010 at 12:23 PM, Richard Jones <rich@annexia.org> wrote:

> How about running the external "uname" program.

Yes, why not. I was hoping that I wouldn't have to resort to that kind
of hacks, that I was missing a function using uname(3) directly.

On Thu, Jul 8, 2010 at 12:48 PM, Alex <alex.mailinglist@gmx.net> wrote:

> please note, that it's not the runtime configuration
> but the system configuration at compile time of your
> ocaml distribution.

Yes, in fact so is Sys.os_type

Thanks for your answers,

Daniel

Re: [Caml-list] Distinguish between osx and linux programmatically

[Richard Jones]

On Thu, Jul 08, 2010 at 01:09:41PM +0200, Daniel Bünzli wrote:
> On Thu, Jul 8, 2010 at 12:23 PM, Richard Jones <rich@annexia.org> wrote:
> 
> > How about running the external "uname" program.
> 
> Yes, why not. I was hoping that I wouldn't have to resort to that kind
> of hacks, that I was missing a function using uname(3) directly.

Stdlib /could/ bind the uname(2) syscall, but it's legendary in its
complexity.  Seems more likely to cause problems than just calling out
to the external program.

http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NOTES

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Distinguish between osx and linux programmatically

[Romain Beauxis]

Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> Stdlib could bind the uname(2) syscall, but it's legendary in its
> complexity.  Seems more likely to cause problems than just calling out
> to the external program.

I fail to see the complexity.. Where is it ?

Such a function would also be useful for cross-compiling, I think..

Romain

Re: [Caml-list] Distinguish between osx and linux programmatically

[Richard Jones]

On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > Stdlib could bind the uname(2) syscall, but it's legendary in its
> > complexity.  Seems more likely to cause problems than just calling out
> > to the external program.
> 
> I fail to see the complexity.. Where is it ?

Actually *I* misunderstood the link I posted
(http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NOTES)
thinking it meant that the string fields in the structure could have
variable width.  Reading it again, they don't.

Nevertheless I still think this is not a useful addition to stdlib,
but for different reasons:

(1) You'd have to emulate it on non-Unix platforms, but it's unclear
what you'd emulate it with.  Windows has a completely different and
much richer concept of OS version.  This sort of version probing
complexity doesn't belong in the core library, but in an external "OS
version" library where detection rules can be frequently updated.

(2) Your program only ever calls out to uname once.  The cost of
running an external program is negligible.

Red Hat recently sponsored an intern to write a library to encode OS
version information:

https://fedorahosted.org/libosinfo/browser/doc/overview.txt

I haven't looked much at it yet beyond reading the documentation.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Distinguish between osx and linux programmatically

[oliver]

On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote:
> On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> > Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > > Stdlib could bind the uname(2) syscall, but it's legendary in its
> > > complexity.  Seems more likely to cause problems than just calling out
> > > to the external program.
> > 
> > I fail to see the complexity.. Where is it ?
> 
> Actually *I* misunderstood the link I posted
> (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NOTES)
> thinking it meant that the string fields in the structure could have
> variable width.  Reading it again, they don't.
> 
> Nevertheless I still think this is not a useful addition to stdlib,
> but for different reasons:
> 
> (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> what you'd emulate it with.  Windows has a completely different and
> much richer concept of OS version.  This sort of version probing
> complexity doesn't belong in the core library, but in an external "OS
> version" library where detection rules can be frequently updated.
[...]


$ uname -a

If it's not Unix, what will uname(2) or uname(1) give you?

What will be reported on Windows with MinGW or Cygwin?


IMHO using uname(1) is fine.


Ciao,
   Oliver

RE: [Caml-list] Distinguish between osx and linux programmatically

[David Allsopp]

Oliver Bandel wrote: 
> On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote:
> > On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> > > Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > > > Stdlib could bind the uname(2) syscall, but it's legendary in its
> > > > complexity.  Seems more likely to cause problems than just calling
> > > > out to the external program.
> > >
> > > I fail to see the complexity.. Where is it ?
> >
> > Actually *I* misunderstood the link I posted
> > (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NO
> > TES) thinking it meant that the string fields in the structure could
> > have variable width.  Reading it again, they don't.
> >
> > Nevertheless I still think this is not a useful addition to stdlib,
> > but for different reasons:
> >
> > (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> > what you'd emulate it with.  Windows has a completely different and
> > much richer concept of OS version.  This sort of version probing
> > complexity doesn't belong in the core library, but in an external "OS
> > version" library where detection rules can be frequently updated.
> [...]
> 
> 
> $ uname -a
> 
> If it's not Unix, what will uname(2) or uname(1) give you?
> 
> What will be reported on Windows with MinGW

C:\Users\DRA>uname -a
windows32 Tenor 2.6.1 7600 i686-pc Intel unknown MinGW

(using GnuWin32 which is a MinGW build of the Unix tools)

> or Cygwin?

DRA@Tenor ~
$ uname -a
CYGWIN_NT-6.1-WOW64 Tenor 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

But of course in both instances that requires uname.exe to be installed which it won't be on most normal end-user systems.


David

Re: [Caml-list] Distinguish between osx and linux programmatically

[Török Edwin]

On Thu, 8 Jul 2010 17:22:15 +0000
David Allsopp <dra-news@metastack.com> wrote:

> Oliver Bandel wrote: 
> > On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote:
> > > On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> > > > Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > > > > Stdlib could bind the uname(2) syscall, but it's legendary in
> > > > > its complexity.  Seems more likely to cause problems than
> > > > > just calling out to the external program.
> > > >
> > > > I fail to see the complexity.. Where is it ?
> > >
> > > Actually *I* misunderstood the link I posted
> > > (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NO
> > > TES) thinking it meant that the string fields in the structure
> > > could have variable width.  Reading it again, they don't.
> > >
> > > Nevertheless I still think this is not a useful addition to
> > > stdlib, but for different reasons:
> > >
> > > (1) You'd have to emulate it on non-Unix platforms, but it's
> > > unclear what you'd emulate it with.  Windows has a completely
> > > different and much richer concept of OS version.  This sort of
> > > version probing complexity doesn't belong in the core library,
> > > but in an external "OS version" library where detection rules can
> > > be frequently updated.
> > [...]
> > 
> > 
> > $ uname -a
> > 
> > If it's not Unix, what will uname(2) or uname(1) give you?
> > 
> > What will be reported on Windows with MinGW
> 
> C:\Users\DRA>uname -a
> windows32 Tenor 2.6.1 7600 i686-pc Intel unknown MinGW
> 
> (using GnuWin32 which is a MinGW build of the Unix tools)
> 
> > or Cygwin?
> 
> DRA@Tenor ~
> $ uname -a
> CYGWIN_NT-6.1-WOW64 Tenor 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
> Cygwin
> 
> But of course in both instances that requires uname.exe to be
> installed which it won't be on most normal end-user systems.

OCaml already calls uname(), and has a configure check for its presence:
./configure:  echo "uname() found."
./otherlibs/unix/gethostname.c:  uname(&un);

I think it would only be a matter of using uname() for something more
than just the hostname.

Of course finding out the OS version from uname is more complicated
(Linux has the kernel's version, and there is no way to find out the
distribution, etc.), but a portable program shouldn't care much about
the exact OS version, as long as it knows the OS type.

Best regards,
--Edwin

Re: [Caml-list] Distinguish between osx and linux programmatically

[Romain Beauxis]

Le jeudi 8 juillet 2010 12:01:24, Richard Jones a écrit :
> Actually I misunderstood the link I posted
> (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NOTES)
> thinking it meant that the string fields in the structure could have
> variable width.  Reading it again, they don't.

And they are terminated by a '\0' symbol so we can pass them to 
ocaml_copy_string...

> Nevertheless I still think this is not a useful addition to stdlib,
> but for different reasons:
> 
> (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> what you'd emulate it with.  Windows has a completely different and
> much richer concept of OS version.  This sort of version probing
> complexity doesn't belong in the core library, but in an external "OS
> version" library where detection rules can be frequently updated.

Well, we already have emulation for many things in OCaml, including much more 
complex parts of the POSIX/UNIX API, like signals, select, threads etc..

Most of these functions, when not implemented raise a (mostly) undocumented 
exception on Windows..

I see no reason why the uname "emulation" could not as well raise an exception 
when it is not implemented (e.g. under Win32).

> (2) Your program only ever calls out to uname once.  The cost of
> running an external program is negligible.

In the general case, I prefer to avoid running external programs. This is way 
to much OS-dependent. A builting alternative, if available, is always better..


Romain

Re: [Caml-list] Distinguish between osx and linux programmatically

[oliver]

On Thu, Jul 08, 2010 at 01:09:41PM +0200, Daniel Bünzli wrote:
> On Thu, Jul 8, 2010 at 12:23 PM, Richard Jones <rich@annexia.org> wrote:
> 
> > How about running the external "uname" program.
> 
> Yes, why not. I was hoping that I wouldn't have to resort to that kind
> of hacks, that I was missing a function using uname(3) directly.
[...]

There is uname(1) and uname(2).

Why do you call it "hack"?

You could write a C-binding for uname(2), but does the effort makes sense
for this call?

It's not like you start a whole shell over and over again, just to get
the basename of a file for some 100000 files...

I would assume the call of uname a thing that will be done once
at startup of the program.

For many syscalls I think it makes sense to have them in the stdlib,
but this one is not the one, where I think it's really urgent to have it.

Ciao,
   Oliver