Env

Ruby
1

Hi,

in irb I can have access to ENV[‘COLUMNS’] for the # of columns in the
shell, and works fine.
But inside a script (ruby script.rb), I can’t have access to that hash
key and value.
I’ve done a:

puts ENV.to_a

and i can not see both COLUMNS and LINES
What would be the problem ?

2

On Sat, Feb 10, 2007 at 08:25:09PM +0900, pedro mg wrote:

in irb I can have access to ENV[‘COLUMNS’] for the # of columns in the
shell, and works fine.
But inside a script (ruby script.rb), I can’t have access to that hash
key and value.
I’ve done a:

puts ENV.to_a

and i can not see both COLUMNS and LINES
What would be the problem ?

Nothing to do with ruby…

brian@mappit:~$ echo $COLUMNS
80
brian@mappit:~$ printenv | grep COLUMNS
brian@mappit:~$

This is a shell-internal variable, and not exported by default to
processes
launched from the shell. But it can be if you wish:

brian@mappit:~$ export COLUMNS
brian@mappit:~$ printenv | grep 80
COLUMNS=80
brian@mappit:~$

Brian.

3

Brian C. [email protected] writes:

What would be the problem ?

Nothing to do with ruby…

brian@mappit:~$ echo $COLUMNS
80
brian@mappit:~$ printenv | grep COLUMNS
brian@mappit:~$

This is a shell-internal variable, and not exported by default to processes
launched from the shell. But it can be if you wish:

Well, if that were the case, the variable wouldn’t be visible within
irb, either. Since it is, then it must be an exported environment
variable and not just shell internal.

I think that the problem has to do with how script.rb is being invoked.
Is it started from something other than a terminal session? … perhaps
via a cron job or a startup daemon? If so, then LINES and COLUMNS would
not normally be set, since those environment variables are usually
initialized and exported only within an interactive shell.

4

On Sat, Feb 10, 2007 at 10:56:35PM +0900, Lloyd Z. wrote:

This is a shell-internal variable, and not exported by default to processes
launched from the shell. But it can be if you wish:

Well, if that were the case, the variable wouldn’t be visible within
irb, either. Since it is, then it must be an exported environment
variable and not just shell internal.

Well, on my system:

brian@mappit:~$ irb1.8
irb(main):001:0> ENV.size
=> 39
irb(main):002:0> exit
brian@mappit:~$ ruby1.8 -e ‘puts ENV.size’
37
brian@mappit:~$ printenv | wc -l
37
brian@mappit:~$

So my guess is that irb is setting these variables itself, or calling
some
library which does so (readline perhaps?)

I think that the problem has to do with how script.rb is being invoked.
Is it started from something other than a terminal session? … perhaps
via a cron job or a startup daemon? If so, then LINES and COLUMNS would
not normally be set, since those environment variables are usually
initialized and exported only within an interactive shell.

I thought of that, but all the examples shown above and in my previous
reply
were typed into a terminal session.

Regards,

Brian.

5

Brian C. [email protected] writes:

brian@mappit:~$ irb1.8
library which does so (readline perhaps?)
Yes, it looks like the shell is not exporting those environment
variables, after all. Therefore, I agree that it’s probably irb who is
setting and exporting them.

If you’re running under Linux and you need these variables to be
exported, you could eval the /usr/bin/resize command as part of your
shell startup commands. In bash, for example, you could put the
following into your ~/.bash_profile or ~/.bash_login:

eval /usr/bin/resize

This will ensure that all of your interactive shells will have these
variables set and exported, so you can then find them inside of the ENV
object within ruby.

… or you could even put this into /etc/profile, to ensure that all
interactive users get these variables exported to their interactive
shells during login.

If you want to query these values directly from ruby without relying on
externally set environment variables, and if you know you’re going to
always be running under Linux, check this out:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/40350

6

akbarhome wrote:

ENV[‘COLUMNS’] does not matter.
sorry but that seems not to be a satisfactory explanation.
Just because it is not clear whether the ruby script needs terminal,
that features is cutted out ?

In this case, i need to know the # of terminal window columns for my
terminal client app. So, it matters.
Is there any way to get it ?

7

akbarhome wrote:

Because when you play with irb, it is clear that you use terminal/
console so ENV[‘COLUMNS’] does matter. But when you execute ruby
script, it is not clear whether this ruby script need terminal so
ENV[‘COLUMNS’] does not matter.

akbarhome, unless what you mean is: that info is not available because
you need to call another lib :wink: Is that what you meant ?

8

On Feb 10, 3:48 pm, pedro mg [email protected] wrote:

Hi,

in irb I can have access to ENV[‘COLUMNS’] for the # of columns in the
shell, and works fine.
But inside a script (ruby script.rb), I can’t have access to that hash
key and value.
I’ve done a:

Because when you play with irb, it is clear that you use terminal/
console so ENV[‘COLUMNS’] does matter. But when you execute ruby
script, it is not clear whether this ruby script need terminal so
ENV[‘COLUMNS’] does not matter.

9

Brian C. wrote:

I think that the problem has to do with how script.rb is being invoked.
Is it started from something other than a terminal session? … perhaps
via a cron job or a startup daemon? If so, then LINES and COLUMNS would
not normally be set, since those environment variables are usually
initialized and exported only within an interactive shell.

I thought of that, but all the examples shown above and in my previous reply
were typed into a terminal session.

yes Brian, me too. I’m running the script in a terminal shell.

10

On Feb 10, 2007, at 3:25 AM, pedro mg wrote:

and i can not see both COLUMNS and LINES
What would be the problem ?

COLUMNS isn’t exported. You shouldn’t be able to see it within your
irb session without exporting it or doing something else special.

% echo $COLUMNS
80
% ruby -e ‘p ENV.keys.grep(/COL/)’
[]
% irb

p ENV.keys.grep(/COL/)
[]
=> nil

^d

% export COLUMNS
% ruby -e ‘p ENV.keys.grep(/COL/)’
[“COLUMNS”]
% irb

p ENV.keys.grep(/COL/)
[“COLUMNS”]
=> nil

^d

I suggest you use stty instead.

% ruby -e ‘p stty size.scan(/\d+/).map { |s| s.to_i }’
[24, 80]

11

Ryan D. [email protected] writes:

puts ENV.to_a
[]
% irb

p ENV.keys.grep(/COL/)
[]
=> nil
^d

$ echo $COLUMNS
80
$ ruby -e ‘p ENV[“COLUMNS”]’
nil
$ irb

ENV[“COLUMNS”]
=> “80”
$ irb --noreadline
ENV[“COLUMNS”]
=> nil
^D
$ cd /src/devel/readline/readline-4.2
$ grep setenv *.c
shell.c: setenv (“LINES”, b, 1);
shell.c: setenv (“COLUMNS”, b, 1);

Most people probably don’t consider using irb with readline “special”.
It’s probably only in your shell due to readline, libedit, or similar
in the first place.

$ /bin/ksh
$ echo $COLUMNS

$

Steve