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 ?
--
pedro mg
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.
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 ?
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.
On Feb 10, 3:48 pm, pedro mg <_nospam_s...@tquadrado.com> 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:
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 ?
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]
On Feb 10, 2007, at 3:25 AM, pedro mg wrote:
Brian Candler <B.Candler@pobox.com> writes:
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:
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.
On Sat, Feb 10, 2007 at 08:25:09PM +0900, pedro mg wrote:
brian@mappit:~$ export COLUMNS
brian@mappit:~$ printenv | grep 80
COLUMNS=80
brian@mappit:~$Brian.
--
Lloyd Zusman
ljz@asfast.com
God bless you.
akbarhome wrote:
On Feb 10, 3:48 pm, pedro mg <_nospam_s...@tquadrado.com> 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: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.
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 ?
--
pedro mg
ruby 1.8.4 (2005-12-24) [i486-linux]
ubuntu linux edgy-eft 2.6.17-10-386 #2
Ryan Davis <ryand-ruby@zenspider.com> writes:
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 ?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/)'
% irbp 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
On Feb 10, 2007, at 3:25 AM, pedro mg 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.
On Sat, Feb 10, 2007 at 10:56:35PM +0900, Lloyd Zusman wrote:
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 
Is that what you meant ?
--
pedro mg
Brian Candler <B.Candler@pobox.com> writes:
> 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?)
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
On Sat, Feb 10, 2007 at 10:56:35PM +0900, Lloyd Zusman 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.Regards,
Brian.
--
Lloyd Zusman
ljz@asfast.com
God bless you.
Brian Candler 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.
--
pedro mg
ruby 1.8.4 (2005-12-24) [i486-linux]
ubuntu linux edgy-eft 2.6.17-10-386 #2