Detecting OS from inside julia

[Miguel Bazdresch]

Hi,

I'm considering adding aqua terminal support in Gaston, for OS X users. However, I'd need to be able to find out if the system is actually running on OS X. Is there a way to do this, from inside Julia?

Thanks,

-- mb

[Avik Sengupta]

>run(`uname`)  ?? (and capture the output somehow)

[Keno Fischer]

There's an even easier way. I added CURRENT_OS as a constant a while back.

--

[Miguel Bazdresch]

That'd be a good idea, but I don't know how to capture the output.

(I guess I could create a pipe, redirect uname's output to the pipe, and then read it, but I hope there is an easier way)

-- mb

--

[Miguel Bazdresch]

Excellent. Thank you Keno.

-- mb

--

[Stefan Karpinski]

uname = readchomp(`uname`)

--

[Miguel Bazdresch]

Thank you!

I love and hate undocumented functions. I love that usually there is one that does what I need. I hate that I spent several hours trying (so far unsuccessfully) to work around a problem that readchomp will (probably, easily) solve.

Sorry for the whining.

-- mb

--
 
 
 

[Stefan Karpinski]

Yeah, sorry about that. It's just an abbreviation for chomp(readall(x)) but I found myself doing it often enough to warrant it's own function. Partly it's not documented because I was in the middle of coding, but partly because I generally want to allow things to"bake" for a while before deciding that we want them for good.

--

[Mike Nolta]

Can we rename CURRENT_OS to OS or OS_NAME? I think that would be
easier for people to find.

-Mike

> --

[Stefan Karpinski]

+1 for OS_NAME. What other OS would I care about?

> --
>
>
>

[Keno Fischer]

I'll do the rename.

--

[Avik Sengupta]

CURRENT_OS evaluates to 'OSX' currently on a macbook. I'd posit that it should be 'Darwin' on that system, since the words darwin appears in uname output, and gcc target names. OSX appears in neither. Makefiles also use Darwin (as $(OS)) 

[Keno Fischer]

I will change that as well.

--

[Keno Fischer]

I'm trying to rebuild Julia, but I keep getting this error:

install_name_tool: object: librandom.dylib malformed object (unknown load command 4)

Does anybody know what the problem could be?

[Miguel Bazdresch]

Don't be sorry -- I understand, I was just frustrated.

I would _never_ have thought that readall works on a command.

The good news is, thanks to readchomp, the bindings to gtk-server (http://www.gtk-server.org) I've been working on are closer to release. This means easy GUI programming with julia.

-- mb

--

[Tim Holy]

On Monday, June 25, 2012 12:08:36 PM Miguel Bazdresch wrote:
> This
> means easy GUI programming with julia.

That would be very cool! Looking forward to seeing it!

--Tim

[Stefan Karpinski]

Agreed that will be great to have.

> --
>
>
>

[John Cowan]

On Mon, Jun 25, 2012 at 12:45 PM, Stefan Karpinski
<stefan.k...@gmail.com> wrote:
> +1 for OS_NAME. What other OS would I care about?

Well, when Julia has process migration, the OS might change.

--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures

[Viral Shah]

+Inf

-viral

[dslate]

With the manual a bit out of date, I've found it handy to just type a function name at the interactive prompt to list its methods (or one can use "methods( funcname)").   I've even rummaged around inside the julia source code in search of interesting undocumented functions.  Like Miguel I was surprised to find out that readall took a Cmd as an arg:

Methods for generic function readall

readall(IOStream,) at io.jl:241

readall(String,) at io.jl:245

readall(Union(Set{Port},Port),) at process.jl:491

readall(Union(Set{Cmd},Cmd),) at process.jl:492

Note the somewhat curious method listed for readchomp:

Methods for generic function readchomp

readchomp(Any,) at io.jl:247

I imagine that some of these "rough edges" in the library and documentation are just normal signs of a rapidly-developing language and will eventually be cleaned up.

-- Dave Slate

[Stefan Karpinski]

That's definitely a good thing to do. Since readchomp(x) is just a shorthand for chomp(readall(x)), it will work on anything that readall works on. Since readchomp shouldn't generally know or care what readall works on, there's no constraints on readchomp's argument types. It might be nice to be able to expose inference backwards to see what types of arguments actually make sense for something like readchomp. I guess the answer is "anything for which readall makes sense".