gnat on linux (strange problems and behaviour)

gnat on linux (strange problems and behaviour)

[brian]

I read with interest the postings a few weeks ago where problems were
encountered with running
Gnat on Redhat Linux.
I have just upgraded to Slackware 2.2.6 from 2.0.36.
I seem to have run into problems reinstalling gnat and getting it to
work satisfactory.

1)  I am using gnat-3.11p-i686-pc-linux-gnu-bin ( but have also tried
the other libc1 version)
2)  I cannot even get the script doconfig to work.
It complains
bash: doconfig: command not found

(permissions seem ok)
if I do a "sh doconfig" I get this
doconfig: syntax error near unexpected token `$<'
doconfig: doconfig: line 28: `set x = $<'

3) So I just did a "make"
and all seemed well.
However I cannot get even the simplest executables to run from the
command line in a xterm.
I have to run them from the grasp window  (grasp is the editor I use to
code programs) to work.

Even executables I compiled before the upgrade are having this trouble.
Could I be missing something really basic? Is the problem related to
using the "make" command
and bypassing the doconfig/doinstall step? A problem with the KDE
desktop which is new to me?

Any help greatly appreciated
Regards
Brian

Re: gnat on linux (strange problems and behaviour)

[Simon Wright]

brian <brianc@billybob.demon.co.uk> writes:

> 1)  I am using gnat-3.11p-i686-pc-linux-gnu-bin ( but have also tried
> the other libc1 version)
> 2)  I cannot even get the script doconfig to work.
> It complains
> bash: doconfig: command not found
> 
> (permissions seem ok)

Try "./doconfig" instead of just "doconfig"? (ie, is "." on your path?)

> if I do a "sh doconfig" I get this
> doconfig: syntax error near unexpected token `$<'
> doconfig: doconfig: line 28: `set x = $<'

Looks like a csh construct.

If you look at the top of doconfig, what does it say? I only have
gnat-3.11p-i386-pc-solaris2.6-bin here, which requires csh not sh.

try "csh doconfig"

> 3) So I just did a "make"
> and all seemed well.
> However I cannot get even the simplest executables to run from the
> command line in a xterm.
> I have to run them from the grasp window  (grasp is the editor I use to
> code programs) to work.
> 
> Even executables I compiled before the upgrade are having this trouble.
> Could I be missing something really basic? Is the problem related to
> using the "make" command
> and bypassing the doconfig/doinstall step? A problem with the KDE
> desktop which is new to me?

Sounds like a shared library path problem; a proper installation will
probably fix this.

Re: gnat on linux (strange problems and behaviour)

[Clayton Weaver]

You know how sh is often a symbolic link to bash on linux?
The tcsh from slackware 3.4 (probably any other distribution's
tcsh is the same source) can emulate csh the same way (needed it to
install lclint without rewriting the csh syntax in the makefile targets).

Regards,

Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)

"Everybody's ignorant, just in different subjects."  Will Rogers



-- 

Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)

Re: gnat on linux (strange problems and behaviour)

[brian]

The problem ended up being that the '. 'directory was not in my path.

Which quite surprised me as I don't remember any options where I
 decided not to put it in my Path on my new install  :-)      maybe /bin is
missing too :-)

Thanks to all who helped .
(and Magnus L  and Fred L.)

_________________________________________________________________
Brian,  London U.K.
brianc@billybob.demon.co.uk

Re: gnat on linux (strange problems and behaviour)

[Samuel Tardieu]

>>>>> "Brian" == brian  <brianc@billybob.demon.co.uk> writes:

Brian> The problem ended up being that the '. 'directory was not in my
Brian> path.  Which quite surprised me as I don't remember any options
Brian> where I decided not to put it in my Path on my new install

Well, it is a safe choice not to have "." in your PATH as far as
security is concerned: you can be in whatever directory you want, you
will not take the risk of calling commands outside of the safe PATH
you defined unless you explicitely provide the "./".

Of course, if you are not using a multiuser system, this is overkill.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: gnat on linux (strange problems and behaviour)

[Robert Dewar]

In article <37BEA492.413D9707@ebox.tninet.se>,
  Stefan Skoglund <stetson@ebox.tninet.se> wrote:
> a software package should never require . in the PATH.
> This is most definitely broken !!!
>
> Consider the existence of trojans.

Sorry I do not see what you are talking about. As Sam said,
if you have a single user machine on which you control all
software on the machine, and no one else uses it, then
putting . in your path is not a problem.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: gnat on linux (strange problems and behaviour)

[Robert Dewar]

In article <37BEA492.413D9707@ebox.tninet.se>,
  Stefan Skoglund <stetson@ebox.tninet.se> wrote:
>
> a software package should never require . in the PATH.
> This is most definitely broken !!!
>
> Consider the existence of trojans.


Indeed, to add to my previous remark, if you only ever enter
commands in your own directories, and you have total control
over these directories, it is also perfectly safe to have
. in the path. The danger comes in multi-user systems where
you roam around, e.g. entering an ls command in a directory
that is not under your control.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: gnat on linux (strange problems and behaviour)

[Stefan Skoglund]

Samuel Tardieu wrote:
> Well, it is a safe choice not to have "." in your PATH as far as
> security is concerned: you can be in whatever directory you want, you
> will not take the risk of calling commands outside of the safe PATH
> you defined unless you explicitely provide the "./".
> 
> Of course, if you are not using a multiuser system, this is overkill.
> 

a software package should never require . in the PATH.
This is most definitely broken !!!

Consider the existence of trojans.

Re: gnat on linux (strange problems and behaviour)

[Mario Klebsch]

Robert Dewar <robert_dewar@my-deja.com> writes:

>In article <37BEA492.413D9707@ebox.tninet.se>,
>  Stefan Skoglund <stetson@ebox.tninet.se> wrote:
>> a software package should never require . in the PATH.
>> This is most definitely broken !!!

>Sorry I do not see what you are talking about. As Sam said,
>if you have a single user machine on which you control all
>software on the machine, and no one else uses it, then
>putting . in your path is not a problem.

But no piece of software should require or rely on having . in $PATH.
So when writing software it is best assuption about $PATH is, that
is contains only garbage, especially do not assume, that the directory
containing your program is included in $PATH.

73, Mario
--
Mario Klebsch		Mario.Klebsch@braunschweig.netsurf.de

Re: gnat on linux (strange problems and behaviour)

[Robert Dewar]

In article <o7uop7.l72.ln@ds9.uucp>,
  Mario Klebsch <Mario.Klebsch@braunschweig.netsurf.de> wrote:
> But no piece of software should require or rely on having . in
> $PATH.

Well of course, no one could disagree with that, and no software
in sight does violate this obvious rule, or think of violating
it, so this is a *true* straw man!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.