Hi,
I am running a Linux C compiled program for my project. The program
was in a script named as 'run0', see below. In the same directory,
there is another script file named: 'ex0'. In 'ex0', a C compiled
program named exec0.

When I run './run0' at the prompt, it feedbacks:

../run0: line 10: ex0 command not found.

I see that all the command exec needs './', but the provided script
without a single './' Because there are a lot of files called in the
script, I want to know how to make the Linux OPENSUSE run directly.


BTW, I have run:
$PATH=$PATH:.

It seems no use at all.

Please help me on how to run scripts (two levels in my routines)
without './'

Thanks.




.....
#!/bin/sh
# Run all the examples, and check the output against the corresponding
-out
# file.  Note that slight differences are possible when the examples
are
# run on different machines, due to slightly different round-off
errors.
for e in `ls ex0* | grep -v "\\." | grep -v .-out`
do
 echo Running $e:
 $e 2>&1 | diff {e}-out -
 echo " "
done

On 2011-05-13, fl wrote:
> Hi,
> I am running a Linux C compiled program for my project. The program
> was in a script named as 'run0', see below. In the same directory,
> there is another script file named: 'ex0'. In 'ex0', a C compiled
> program named exec0.
>
> When I run './run0' at the prompt, it feedbacks:
>
> ./run0: line 10: ex0 command not found.
>
> I see that all the command exec needs './', but the provided script
> without a single './' Because there are a lot of files called in the
> script, I want to know how to make the Linux OPENSUSE run directly.

   Put all scripts and executables in a direectory that is in your
   $PATH, e.g. $HOME/bin

> BTW, I have run:
> $PATH=$PATH:.

   That would give you an error; perhaps you meant:

PATH=$PATH:.
export PATH

   But don't do that.

-- 
   Chris F.A. Johnson, <http://cfajohnson.com>
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

On 2011-05-13, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> On 2011-05-13, fl wrote:
>> Hi,
>> I am running a Linux C compiled program for my project. The program
>> was in a script named as 'run0', see below. In the same directory,
>> there is another script file named: 'ex0'. In 'ex0', a C compiled
>> program named exec0.
>>
>> When I run './run0' at the prompt, it feedbacks:
>>
>> ./run0: line 10: ex0 command not found.
>>
>> I see that all the command exec needs './', but the provided script
>> without a single './' Because there are a lot of files called in the
>> script, I want to know how to make the Linux OPENSUSE run directly.
>
>    Put all scripts and executables in a direectory that is in your
>    $PATH, e.g. $HOME/bin
>
>> BTW, I have run:
>> $PATH=$PATH:.
>
>    That would give you an error; perhaps you meant:
>
> PATH=$PATH:.
> export PATH
>
>    But don't do that.

Putting . in $PATH _used_ to be standard practice.  I believe my
K&R mentiones just typing "a.out" to run a just-compiled program
with _no_ "./" in front of it.

Nowadays, it depends on your environment.  If you're talking
about the root account or an account at a university or in a
company where there is significant risk of a malicious user on
the inside, don't put . in $PATH.  However, for a non-root
account on a well-secured system with essentially zero likelihood
of a malicious user or prankster on the inside, there are _FAR_
more serious security fish to fry.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

In article <slrnispci5.fe0.spamtrap42@one.localnet>,
Robert Riches  <spamtrap42@verizon.net> wrote:
....
>Putting . in $PATH _used_ to be standard practice.  I believe my
>K&R mentiones just typing "a.out" to run a just-compiled program
>with _no_ "./" in front of it.
>
>Nowadays, it depends on your environment.  If you're talking
>about the root account or an account at a university or in a
>company where there is significant risk of a malicious user on
>the inside, don't put . in $PATH.  However, for a non-root
>account on a well-secured system with essentially zero likelihood
>of a malicious user or prankster on the inside, there are _FAR_
>more serious security fish to fry.

Well said, sir!

I would like to add that this problem can be interpreted at 2 levels.  The
first level is the usual "Dot in your PATH" bugaboo - which could be
catalogued as "Unix Gotcha #5" - and which we've all hit at some point in
our Unix education.

But at a higher level, the point is that the OP's real problem seems to be
that he is using a system-supplied script (a starter script for some piece
of software) - that *should* work - that it doesn't seem to be working,
without him hacking on it (setting PATHs and so on), indicates that
something deeper is going on.

-- 
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

    (Paul Krugman - Addicted to Bush)

On 13/05/2011 06:23, Robert Riches wrote:
> On 2011-05-13, Chris F.A. Johnson<cfajohnson@gmail.com>  wrote:
>> On 2011-05-13, fl wrote:
>>> Hi,
>>> I am running a Linux C compiled program for my project. The program
>>> was in a script named as 'run0', see below. In the same directory,
>>> there is another script file named: 'ex0'. In 'ex0', a C compiled
>>> program named exec0.
>>>
>>> When I run './run0' at the prompt, it feedbacks:
>>>
>>> ./run0: line 10: ex0 command not found.
>>>
>>> I see that all the command exec needs './', but the provided script
>>> without a single './' Because there are a lot of files called in the
>>> script, I want to know how to make the Linux OPENSUSE run directly.
>>
>>     Put all scripts and executables in a direectory that is in your
>>     $PATH, e.g. $HOME/bin
>>
>>> BTW, I have run:
>>> $PATH=$PATH:.
>>
>>     That would give you an error; perhaps you meant:
>>
>> PATH=$PATH:.
>> export PATH
>>
>>     But don't do that.
>
> Putting . in $PATH _used_ to be standard practice.  I believe my
> K&R mentiones just typing "a.out" to run a just-compiled program
> with _no_ "./" in front of it.
>
> Nowadays, it depends on your environment.  If you're talking
> about the root account or an account at a university or in a
> company where there is significant risk of a malicious user on
> the inside, don't put . in $PATH.  However, for a non-root
> account on a well-secured system with essentially zero likelihood
> of a malicious user or prankster on the inside, there are _FAR_
> more serious security fish to fry.
>

Avoiding . in $PATH is not just a security issue - it's an accident 
avoidance issue.  It's like the "x" permission bit - it's not there to 
stop you running malicious programs (malware didn't really exist when it 
was introduced).  It's about making it easier to run the programs you 
intend to run, and not accidentally running something else.

Typing "./" before programs in your current directory is hardly a 
hardship - but if it is, put . in your $PATH if you want.  It's /your/ 
machine, and /your/ choice.

On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:

> Typing "./" before programs in your current directory is hardly a
> hardship - but if it is, put . in your $PATH if you want.  It's /your/
> machine, and /your/ choice.

It may not be a hardship, but it's certainly an annoyance.

Todd

Todd Carnes <toddcarnes@gmail.com> writes:

> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
>
>> Typing "./" before programs in your current directory is hardly a
>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>> machine, and /your/ choice.
>
> It may not be a hardship, but it's certainly an annoyance.

Complaining that it's an annoyance just seems odd.
It was just mentioned that it's your choice.

-- 
Dan Espen

On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
>
>> Typing "./" before programs in your current directory is hardly a
>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>> machine, and /your/ choice.
>
> It may not be a hardship, but it's certainly an annoyance.

Why? You surely have your runnable programs in specific directories. JUt
put them into your path. Having runable probramms scattered all over
hell's half acre is even more of an annoyance.
>
> Todd

In article <slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
unruh  <unruh@wormhole.physics.ubc.ca> wrote:
> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
> > On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
> >
> >> Typing "./" before programs in your current directory is hardly a
> >> hardship - but if it is, put . in your $PATH if you want.  It's /your/
> >> machine, and /your/ choice.
> >
> > It may not be a hardship, but it's certainly an annoyance.
> 
> Why? You surely have your runnable programs in specific directories. JUt
> put them into your path. Having runable probramms scattered all over
> hell's half acre is even more of an annoyance.

I guess if you don't do much code development that might be true,
but, um, surely if you're writing code (including shell scripts),
executing files in the current directory, or a nearby directory, is
something you're going to do a lot?  I don't mind including the "./",
and in fact it avoids any possible ambiguity, but the idea that *all*
executables live in directories in $PATH seems -- wrong.  ?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

blmblm@myrealbox.com wrote:
> In article <slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
> unruh  <unruh@wormhole.physics.ubc.ca> wrote:
>> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
>>> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
>>>
>>>> Typing "./" before programs in your current directory is hardly a
>>>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>>>> machine, and /your/ choice.
>>> It may not be a hardship, but it's certainly an annoyance.
>> Why? You surely have your runnable programs in specific directories. JUt
>> put them into your path. Having runable probramms scattered all over
>> hell's half acre is even more of an annoyance.
> 
> I guess if you don't do much code development that might be true,
> but, um, surely if you're writing code (including shell scripts),
> executing files in the current directory, or a nearby directory, is
> something you're going to do a lot?  I don't mind including the "./",
> and in fact it avoids any possible ambiguity, but the idea that *all*
> executables live in directories in $PATH seems -- wrong.  ?
> 
$PATH is there to help you find stuff that is production code and sorted 
accordingly.

If you are writing custom stuff you are assumed to have the nous to know 
how to execute it.

On 27/06/2011 23:42, blmblm@myrealbox.com wrote:
> In article<slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
> unruh<unruh@wormhole.physics.ubc.ca>  wrote:
>> On 2011-06-26, Todd Carnes<toddcarnes@gmail.com>  wrote:
>>> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
>>>
>>>> Typing "./" before programs in your current directory is hardly a
>>>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>>>> machine, and /your/ choice.
>>>
>>> It may not be a hardship, but it's certainly an annoyance.
>>
>> Why? You surely have your runnable programs in specific directories. JUt
>> put them into your path. Having runable probramms scattered all over
>> hell's half acre is even more of an annoyance.
>
> I guess if you don't do much code development that might be true,
> but, um, surely if you're writing code (including shell scripts),
> executing files in the current directory, or a nearby directory, is
> something you're going to do a lot?  I don't mind including the "./",
> and in fact it avoids any possible ambiguity, but the idea that *all*
> executables live in directories in $PATH seems -- wrong.  ?
>

A very common solution is to have /home/$USER/bin on your $PATH, and put 
symbolic links there that link to the real program.  The program itself 
doesn't have to be in a common bin directory (I agree that's impractical 
for code development).

blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> writes:
> unruh <unruh@wormhole.physics.ubc.ca> wrote:
>> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
>>> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:

>>>> Typing "./" before programs in your current directory is hardly a
>>>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>>>> machine, and /your/ choice.
>>>
>>> It may not be a hardship, but it's certainly an annoyance.
>> 
>> Why? You surely have your runnable programs in specific directories. JUt
>> put them into your path. Having runable probramms scattered all over
>> hell's half acre is even more of an annoyance.
>
> I guess if you don't do much code development that might be true,
> but, um, surely if you're writing code (including shell scripts),
> executing files in the current directory, or a nearby directory, is
> something you're going to do a lot?  I don't mind including the "./",
> and in fact it avoids any possible ambiguity, but the idea that *all*
> executables live in directories in $PATH seems -- wrong.  ?

So you either type suitable relative paths (quite possibly not "./", in
a nontrivial project the executables may well not be in the top level)
or transiently add those directories to $PATH (something I usually only
do in test scripts).  None of this is rocket science.

-- 
http://www.greenend.org.uk/rjk/

Richard Kettlewell wrote:

>None of this is rocket science.
> 
Rocket science is over rated anyway. All there is to rocket science is

F = m * a

Now getting a rocket up, especially like to the moon or another planet
is more complicated, but that is rocket engineering. The Chinese
discovered rockets almost 1000 years ago.

There are bumper stickers where I live saying that my congressman _is_ a
rocket scientist. Which is kind-of funny because he used to be a
scientist (physicist) at Princeton, but not in the field of rockets.

-- 
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 08:50:01 up 5 days, 22:21, 3 users, load average: 5.02, 4.95, 4.83

On 2011-06-28, Jean-David Beyer <jeandavid8@verizon.net> wrote:
> Richard Kettlewell wrote:
>
>>None of this is rocket science.
>> 
> Rocket science is over rated anyway. All there is to rocket science is
>
> F = m * a

Indeed.

Rocket science is easy.

It's rocket _engineering_ that's hard.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm wearing PAMPERS!!
                                  at               
                              gmail.com            

In article <qIOdnZCCr4ir5JTTnZ2dnUVZ8i2dnZ2d@lyse.net>,
David Brown  <david@westcontrol.removethisbit.com> wrote:
> On 27/06/2011 23:42, blmblm@myrealbox.com wrote:
> > In article<slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
> > unruh<unruh@wormhole.physics.ubc.ca>  wrote:
> >> On 2011-06-26, Todd Carnes<toddcarnes@gmail.com>  wrote:
> >>> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
> >>>
> >>>> Typing "./" before programs in your current directory is hardly a
> >>>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
> >>>> machine, and /your/ choice.
> >>>
> >>> It may not be a hardship, but it's certainly an annoyance.
> >>
> >> Why? You surely have your runnable programs in specific directories. JUt
> >> put them into your path. Having runable probramms scattered all over
> >> hell's half acre is even more of an annoyance.
> >
> > I guess if you don't do much code development that might be true,
> > but, um, surely if you're writing code (including shell scripts),
> > executing files in the current directory, or a nearby directory, is
> > something you're going to do a lot?  I don't mind including the "./",
> > and in fact it avoids any possible ambiguity, but the idea that *all*
> > executables live in directories in $PATH seems -- wrong.  ?
> >
> 
> A very common solution is to have /home/$USER/bin on your $PATH, and put 
> symbolic links there that link to the real program.  The program itself 
> doesn't have to be in a common bin directory (I agree that's impractical 
> for code development).

I guess that's an improvement, but if you write a lot of throwaway
programs (as some of us do?), then you have to think about whether
you're cluttering up $HOME/bin with links that will break, don't you?

The point I was trying to make ....  More in response to another post.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <87wrg6z5ux.fsf@araminta.anjou.terraraq.org.uk>,
Richard Kettlewell  <rjk@greenend.org.uk> wrote:
> blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> writes:
> > unruh <unruh@wormhole.physics.ubc.ca> wrote:
> >> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
> >>> On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
> 
> >>>> Typing "./" before programs in your current directory is hardly a
> >>>> hardship - but if it is, put . in your $PATH if you want.  It's /your/
> >>>> machine, and /your/ choice.
> >>>
> >>> It may not be a hardship, but it's certainly an annoyance.
> >> 
> >> Why? You surely have your runnable programs in specific directories. JUt
> >> put them into your path. Having runable probramms scattered all over
> >> hell's half acre is even more of an annoyance.
> >
> > I guess if you don't do much code development that might be true,
> > but, um, surely if you're writing code (including shell scripts),
> > executing files in the current directory, or a nearby directory, is
> > something you're going to do a lot?  I don't mind including the "./",
> > and in fact it avoids any possible ambiguity, but the idea that *all*
> > executables live in directories in $PATH seems -- wrong.  ?
> 
> So you either type suitable relative paths (quite possibly not "./", in
> a nontrivial project the executables may well not be in the top level)
> or transiently add those directories to $PATH (something I usually only
> do in test scripts).  None of this is rocket science.

Oh sure.  The point I was trying to make is that the comment
about not scattering executable files all over seemed aimed more
at people who do not regularly develop code.  (I sometimes have to
remind myself that most users are probably in that category!)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On 2011-06-27, blmblm  myrealbox.com wrote:
> In article <slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
> unruh  <unruh@wormhole.physics.ubc.ca> wrote:
>> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
>> > On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
>> >
>> >> Typing "./" before programs in your current directory is hardly a
>> >> hardship - but if it is, put . in your $PATH if you want.  It's /your/
>> >> machine, and /your/ choice.
>> >
>> > It may not be a hardship, but it's certainly an annoyance.
>> 
>> Why? You surely have your runnable programs in specific directories. JUt
>> put them into your path. Having runable probramms scattered all over
>> hell's half acre is even more of an annoyance.
>
> I guess if you don't do much code development that might be true,
> but, um, surely if you're writing code (including shell scripts),
> executing files in the current directory, or a nearby directory, is
> something you're going to do a lot?  I don't mind including the "./",
> and in fact it avoids any possible ambiguity, but the idea that *all*
> executables live in directories in $PATH seems -- wrong.  ?

   I am constantly writing shell scripts, and I never put them
   anywhere but in a directory that is in my $PATH.

   On the odd occasion that I write something in C, it goes in a
   directory for that project (or a misc directory for snippets).


-- 
   Chris F.A. Johnson, <http://cfajohnson.com>
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

On 12.05.2011 19:56, fl wrote:
> Hi,
> I am running a Linux C compiled program for my project. The program
> was in a script named as 'run0', see below. In the same directory,
> there is another script file named: 'ex0'. In 'ex0', a C compiled
> program named exec0.
>
> When I run './run0' at the prompt, it feedbacks:
>
> ./run0: line 10: ex0 command not found.
>
> I see that all the command exec needs './', but the provided script
> without a single './' Because there are a lot of files called in the
> script, I want to know how to make the Linux OPENSUSE run directly.
>
>
> BTW, I have run:
> $PATH=$PATH:.
>
> It seems no use at all.
>
> Please help me on how to run scripts (two levels in my routines)
> without './'
>
> Thanks.


Put those executables in /usr/local/bin
Libraries if they are any, in /usr/local/lib

In article <7l0qd8-dv4.ln1@206-248-139-163.dsl.teksavvy.com>,
Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> On 2011-06-27, blmblm  myrealbox.com wrote:
> > In article <slrnj0gknf.7ds.unruh@wormhole.physics.ubc.ca>,
> > unruh  <unruh@wormhole.physics.ubc.ca> wrote:
> >> On 2011-06-26, Todd Carnes <toddcarnes@gmail.com> wrote:
> >> > On Fri, 13 May 2011 13:02:52 +0200, David Brown wrote:
> >> >
> >> >> Typing "./" before programs in your current directory is hardly a
> >> >> hardship - but if it is, put . in your $PATH if you want.  It's /your/
> >> >> machine, and /your/ choice.
> >> >
> >> > It may not be a hardship, but it's certainly an annoyance.
> >> 
> >> Why? You surely have your runnable programs in specific directories. JUt
> >> put them into your path. Having runable probramms scattered all over
> >> hell's half acre is even more of an annoyance.
> >
> > I guess if you don't do much code development that might be true,
> > but, um, surely if you're writing code (including shell scripts),
> > executing files in the current directory, or a nearby directory, is
> > something you're going to do a lot?  I don't mind including the "./",
> > and in fact it avoids any possible ambiguity, but the idea that *all*
> > executables live in directories in $PATH seems -- wrong.  ?
> 
>    I am constantly writing shell scripts, and I never put them
>    anywhere but in a directory that is in my $PATH.

Even the throwaways?  seems like it makes more sense to keep those
separate from stuff one wants to have in one's semi-permanent
toolkit ....  But maybe you *do* make that distinction; it's not
as if $PATH is limited to a single directory.  

>    On the odd occasion that I write something in C, it goes in a
>    directory for that project (or a misc directory for snippets).

So it sounds like you have a different organizational scheme for
C programs than for shell scripts.  Why is that?  (I'm just curious
about people's organizational schemes, I guess.)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.