ACCESS TO SYSTEM VARIABLES

ACCESS TO SYSTEM VARIABLES

[Emile8]

On Linux I want to know the number of lines and columns of my working
terminal. When on the command line I call by hand the system variables
$LINES and $COLUMNS, I get the right answers.

When I try to do the same from a program written in Gnat Ada 2005
(Year 2010) using the specialized package Ada.Environment_Variables,
as in the following code called from the same terminal, I get no
answer for COLUMNS and LINES as if the corresponding system variables
do not exist (I get a correct answer for PATH).


with Ada.Environment_Variables; use Ada.Environment_Variables;
with Ada.Text_Io; use Ada.Text_Io;

procedure Print_Env is
begin
Put_Line("Columns : " & Value("COLUMNS"));
Put_Line("Lines : " & Value("LINES"));
Put_Line("Path : " & Value("PATH"));
end Print_Env;


I would like to understand the reasons of this behavior. Are there
different kinds of system variables in Linux ? Those as HOME, PATH
whose values depend only on the user session and those as LINES,
COLUMNS defined for each used terminal. Is there a way in Ada to
overcome this limitation ?

Re: ACCESS TO SYSTEM VARIABLES

[Georg Bauhaus]

On 07.03.11 10:34, Emile8 wrote:

> with Ada.Environment_Variables; use Ada.Environment_Variables;
> with Ada.Text_Io; use Ada.Text_Io;
> 
> procedure Print_Env is
> begin
> Put_Line("Columns : " & Value("COLUMNS"));
> Put_Line("Lines : " & Value("LINES"));
> Put_Line("Path : " & Value("PATH"));
> end Print_Env;
> 
> 
> I would like to understand the reasons of this behavior. Are there
> different kinds of system variables in Linux ? Those as HOME, PATH
> whose values depend only on the user session and those as LINES,
> COLUMNS defined for each used terminal. Is there a way in Ada to
> overcome this limitation ?

Variables LINES and COLUMNS might not have been marked for export.
Try export -p.

With the above program, I see constraint errors for LINES and
COLUMNS when these don't exist in the environment (which is
expected behavior).

$ LINES=$LINES COLUMNS=$COLUMNS ./print_env
Columns : 255
Lines : 42
Path : /usr/local/bin:/usr/bin:/bin:/usr/games

Re: ACCESS TO SYSTEM VARIABLES

[Adam Beneschan]

On Mar 7, 3:47 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 07.03.11 10:34, Emile8 wrote:
>
>
>
>
>
> > with Ada.Environment_Variables; use Ada.Environment_Variables;
> > with Ada.Text_Io; use Ada.Text_Io;
>
> > procedure Print_Env is
> > begin
> > Put_Line("Columns : " & Value("COLUMNS"));
> > Put_Line("Lines : " & Value("LINES"));
> > Put_Line("Path : " & Value("PATH"));
> > end Print_Env;
>
> > I would like to understand the reasons of this behavior. Are there
> > different kinds of system variables in Linux ? Those as HOME, PATH
> > whose values depend only on the user session and those as LINES,
> > COLUMNS defined for each used terminal. Is there a way in Ada to
> > overcome this limitation ?
>
> Variables LINES and COLUMNS might not have been marked for export.
> Try export -p.
>
> With the above program, I see constraint errors for LINES and
> COLUMNS when these don't exist in the environment (which is
> expected behavior).
>
> $ LINES=$LINES COLUMNS=$COLUMNS ./print_env
> Columns : 255
> Lines : 42
> Path : /usr/local/bin:/usr/bin:/bin:/usr/games

That's if you're using bash.  In csh

  set LINES=42

will not make the variable LINES available in the environment, but
this will:

  setenv LINES 42

                         -- Adam

Re: ACCESS TO SYSTEM VARIABLES

[Emile8]

On 7 mar, 12:47, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> On 07.03.11 10:34, Emile8 wrote:
>
>
>
> > with Ada.Environment_Variables; use Ada.Environment_Variables;
> > with Ada.Text_Io; use Ada.Text_Io;
>
> > procedure Print_Env is
> > begin
> > Put_Line("Columns : " & Value("COLUMNS"));
> > Put_Line("Lines : " & Value("LINES"));
> > Put_Line("Path : " & Value("PATH"));
> > end Print_Env;
>
> > I would like to understand the reasons of this behavior. Are there
> > different kinds of system variables in Linux ? Those as HOME, PATH
> > whose values depend only on the user session and those as LINES,
> > COLUMNS defined for each used terminal. Is there a way in Ada to
> > overcome this limitation ?
>
> Variables LINES and COLUMNS might not have been marked for export.
> Try export -p.
>
> With the above program, I see constraint errors for LINES and
> COLUMNS when these don't exist in the environment (which is
> expected behavior).
>
> $ LINES=$LINES COLUMNS=$COLUMNS ./print_env
> Columns : 255
> Lines : 42
> Path : /usr/local/bin:/usr/bin:/bin:/usr/games

I tried your suggestion which in fact solves only part of the problem.
With this approach the Ada program manages well to get the right
initial values for the Lines and Columns of the terminal, but  when I
use it in a loop to monitor a manual resizing of the terminal, it does
not see the changes in LINES and COLUMNS and reports always the same
initial values. This behavior persists even if each  LINES and COLUMNS
variables acquisitions are preceded by an export-p command.

I finally found a solution making in the Ada program the bash command
"stty size > TermSize.txt" which reports in the dedicated file
TermSize.txt the two numbers for LINES and COLUMNS. A reading of this
file brings back in the  Ada program the two numbers. This approach
works well when the terminal is resized. The next best thing would be
now to be able to manage the terminal as a protected object in Ada and
to have always an exact knowledge of its dimensions when I want tu use
it. But it is certainly only a dream...

It is not a very elegant solution and I should look also at how the
Ada version of ncurses manages to get the same informations.

Re: ACCESS TO SYSTEM VARIABLES

[Peter C. Chapin]

On Mon, 7 Mar 2011, Emile8 wrote:

> It is not a very elegant solution and I should look also at how the
> Ada version of ncurses manages to get the same informations.

When the terminal is resized the programs running in it receive a Unix 
signal (SIGWINCH?). By default that signal is ignored. However, one can 
install a signal handler for it and then presumably call into the system 
(some terminal API) to ask for the new sizes.

I could probably figure out how to do this in C, but I'm not familiar with 
how Ada on Unix deals with Unix signals.

Peter

Re: ACCESS TO SYSTEM VARIABLES

[Keith Thompson]

Emile8 <pocchiola.yves@gmail.com> writes:
> On Linux I want to know the number of lines and columns of my working
> terminal. When on the command line I call by hand the system variables
> $LINES and $COLUMNS, I get the right answers.
>
> When I try to do the same from a program written in Gnat Ada 2005
> (Year 2010) using the specialized package Ada.Environment_Variables,
> as in the following code called from the same terminal, I get no
> answer for COLUMNS and LINES as if the corresponding system variables
> do not exist (I get a correct answer for PATH).
>
>
> with Ada.Environment_Variables; use Ada.Environment_Variables;
> with Ada.Text_Io; use Ada.Text_Io;
>
> procedure Print_Env is
> begin
> Put_Line("Columns : " & Value("COLUMNS"));
> Put_Line("Lines : " & Value("LINES"));
> Put_Line("Path : " & Value("PATH"));
> end Print_Env;
>
>
> I would like to understand the reasons of this behavior. Are there
> different kinds of system variables in Linux ? Those as HOME, PATH
> whose values depend only on the user session and those as LINES,
> COLUMNS defined for each used terminal. Is there a way in Ada to
> overcome this limitation ?

$LINES and $COLUMNS are bash shell variables, not environment
variables.  They're not visible from your Ada program any more than
variables declared within your Ada program would be visible from
a shell (even if the shell was launched by your Ada program).

bash probably obtains the values by invoking the ioctl() system
call with TIOCGWINSZ as the second argument.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: ACCESS TO SYSTEM VARIABLES

[Emile8]

On 7 mar, 22:32, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On Mon, 7 Mar 2011, Emile8 wrote:
> > It is not a very elegant solution and I should look also at how the
> > Ada version of ncurses manages to get the same informations.
>
> When the terminal is resized the programs running in it receive a Unix
> signal (SIGWINCH?). By default that signal is ignored. However, one can
> install a signal handler for it and then presumably call into the system
> (some terminal API) to ask for the new sizes.
>
> I could probably figure out how to do this in C, but I'm not familiar with
> how Ada on Unix deals with Unix signals.
>
> Peter

You are right, the approach by a user handler attached to the relevant
UNIX signal is certainly the good approach to cope with terminal
modifications. I am looking at some documentation to understand how to
proceed with these handles in Ada (Rosetta Code ans Big Online Book of
Linux Ada to begin).

Thank you.

Re: ACCESS TO SYSTEM VARIABLES

[Emile8]

On 8 mar, 18:13, Emile8 <pocchiola.y...@gmail.com> wrote:
> On 7 mar, 22:32, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
>
> > On Mon, 7 Mar 2011, Emile8 wrote:
> > > It is not a very elegant solution and I should look also at how the
> > > Ada version of ncurses manages to get the same informations.
>
> > When the terminal is resized the programs running in it receive a Unix
> > signal (SIGWINCH?). By default that signal is ignored. However, one can
> > install a signal handler for it and then presumably call into the system
> > (some terminal API) to ask for the new sizes.
>
> > I could probably figure out how to do this in C, but I'm not familiar with
> > how Ada on Unix deals with Unix signals.
>
> > Peter
>
> You are right, the approach by a user handler attached to the relevant
> UNIX signal is certainly the good approach to cope with terminal
> modifications. I am looking at some documentation to understand how to
> proceed with these handles in Ada (Rosetta Code ans Big Online Book of
> Linux Ada to begin).
>
> Thank you.

Your suggestion to use a handler on SIGWINCH works fine with the
following Ada package which has simply to be imported by the
application which uses a terminal. The Ansi_Tty_Control package
provides :
   -The N_Columns and N_Lines variables which keep trace of the
terminal size.
   -The Dim_Terminal procedure which reads the terminal sizes

Window resizing and terminal police size change are well detected and
new columns and lines number well reported.

Great !


--SPECIFICATION
with Ada.Interrupts.Names; use Ada.Interrupts, Ada.Interrupts.Names;
package Sigwinchhandler is
   protected Signalhandler is
      procedure Handlewindowresizing;
      pragma Attach_Handler (Handlewindowresizing, SIGWINCH);
      --      SIGWINCH (window resizing) intercepted by
      --      Handlewindowresizing
   end Signalhandler;
end Sigwinchhandler;

-- BODY
with Ada.Text_IO;      use Ada.Text_IO;
with Ansi_Tty_Control; use Ansi_Tty_Control;
package body Sigwinchhandler is
   -- Package to handle SIGWINCH Linux signals
   protected body Signalhandler is
      -- This protected type contains the signal handlers for the
applications
      procedure Handlewindowresizing is
      -- window dimensions handler
      begin
         -- Acquisition of terminal LINES and COLUMNS by bash
command :
         -- stty size > TermSize.txt (waiting for something else more
direct ...)
         Dim_Terminal;
         Put_Line ("Columns : " & Positive'Image (N_Columns));-- Here
the PROOF that it works !
         Put_Line ("Lines   : " & Positive'Image (N_Lines));
      end Handlewindowresizing;
   end Signalhandler;
end Sigwinchhandler;