The Period slash revisited... - Unix

This is a discussion on The Period slash revisited... - Unix ; As I continue on with this tutorial... http://www.ee.surrey.ac.uk/Teaching/Unix/unix7.html I ran across another instance of the ./ that doesn't make sense. It is when configuring a file. The tutorial said that I needed to cd into the appropriate directory and then ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: The Period slash revisited...

  1. The Period slash revisited...

    As I continue on with this tutorial...

    http://www.ee.surrey.ac.uk/Teaching/Unix/unix7.html

    I ran across another instance of the ./ that doesn't make sense.

    It is when configuring a file. The tutorial said that I needed to
    cd into the appropriate directory and then type

    $ ./configure --prefix=$HOME/units174

    well, I tried the configure without the ./ and it gave
    off an error

    $ configure --prefix=$HOME/units174
    bash: configure: command not found
    $ ls -l configure
    -rwxr-xr-x 1 samantha samantha 55018 Aug 2 1999 configure
    $

    is this a specific instance where the ./ doesnt mean the same
    thing as it did in the mv file (if you were here for the last
    discussion there was confusion as to why I needed the ./ during
    a move (see previous post for full story)

    now as far as I can figure out the ./ is needed to execute a
    shell script.. is this right?

    additionally.. further down in the tutorial (after the configure, then
    make, make check, make install it had us cd into the directory where
    the program resided (in the example it was

    % cd ~/units174

    and in order to execute the program it has us (while we were in
    the directory where the file was they had us type:

    % ./units

    to execute this file.. now when I tried that in bash it gave an error

    $ ./units
    units: can't find units file '/usr/local/share/units.dat'

    but when i just typed $ units without the ./ it worked just fine.

    what is the story with ./ ??

    I always understood the . to mean "current directory" it doesn't seem to
    mean that in these instances. I have googled until my fingers are
    worn down trying to figure this out.

    ANY HELP WOULD BE GREATLY APPRECIATED!!!!!

    S.

  2. Re: The Period slash revisited...

    Begin
    On Fri, 11 Jan 2008 00:25:38 -0600, Samantha wrote:
    > I ran across another instance of the ./ that doesn't make sense.

    [snip]
    > well, I tried the configure without the ./ and it gave
    > off an error


    So it does make sense, doesn't it? It makes the example work.
    Now, as to the why...


    > $ configure --prefix=$HOME/units174
    > bash: configure: command not found

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > $ ls -l configure
    > -rwxr-xr-x 1 samantha samantha 55018 Aug 2 1999 configure
    > $
    >
    > is this a specific instance where the ./ doesnt mean the same
    > thing as it did in the mv file (if you were here for the last
    > discussion there was confusion as to why I needed the ./ during
    > a move (see previous post for full story)


    No, '/' is still the directory separator and '.' still means
    *this* directory.

    That is your hint, actually. Obviously, the shell refuses to find
    things that are *right here* in the current directory if you don't
    prefix them with './'. The next question isn't ``what's this with
    './'?'', but should instead be ``how does the shell do its finding?''


    > now as far as I can figure out the ./ is needed to execute a
    > shell script.. is this right?


    Nope. The key is ``find the program'', not ``is it a shellscript?''


    [snip!]
    > I always understood the . to mean "current directory" it doesn't seem to
    > mean that in these instances. I have googled until my fingers are
    > worn down trying to figure this out.


    Yes, it does.

    The shell reads your command and tries to figure out which one it is and
    where to find it. The mechanism works by searching all directories in
    the PATH environment variable[1]. Only. It doesn't look in the current
    directory first. Why should it? If you want that, you can add . to the
    search path.

    In fact, it turns out to be a really bad idea to add . to the search
    path on multi-user machines, and even if you only ever use the machine
    and nobody else is supposed to, it's still a bad idea. The why you can
    figure out as an excercise.

    From that you can probably figure out why your configure command failed
    and `units' seemed to work without `./' prefix. Hint: the program file
    that was executed was not the one you thought was executed.


    [1] Some shells vary a bit by keeping indices and so on. In general,
    this is how it works.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: The Period slash revisited...

    On Fri, 11 Jan 2008 00:25:38 -0600, Samantha wrote:


    >
    > $ ./configure --prefix=$HOME/units174
    >
    > well, I tried the configure without the ./ and it gave off an error
    >
    > $ configure --prefix=$HOME/units174
    > bash: configure: command not found
    > $ ls -l configure
    > -rwxr-xr-x 1 samantha samantha 55018 Aug 2 1999 configure $
    > is this a specific instance where the ./ doesnt mean the same thing as it
    > did in the mv file (if you were here for the last discussion there was
    > confusion as to why I needed the ./ during a move (see previous post for
    > full story)


    > now as far as I can figure out the ./ is needed to execute a shell
    > script.. is this right


    The first word of your input line is the name of the file to
    execute. But your shell looks in only specific directories for commands.
    If you type echo $PATH you will see what your path is. If a file with the
    name configure is found in one of the directories in your path then the
    file will execute if it is executable.
    To tell the shell to run commands not in your PATH you must specify the
    path. Such as ./configure or /home/fred/lesson/builddir/configure.

    For your ./units question, it looks like the script or program ./units
    is trying to access /usr/local/share/units.dat and that file does not
    exist. When you type units without the ./ it is running the units program
    found in your PATH.

    If you want to see what file is really going to run when you type in a
    command, such as ./units or units, you can use the which command.

    % which units


    Does that help?

    stonerfish

  4. Re: The Period slash revisited...

    In article ,
    jpd wrote:

    > Begin
    > On Fri, 11 Jan 2008 00:25:38 -0600, Samantha wrote:
    > > I ran across another instance of the ./ that doesn't make sense.

    > [snip]
    > > well, I tried the configure without the ./ and it gave
    > > off an error

    >
    > So it does make sense, doesn't it? It makes the example work.
    > Now, as to the why...
    >
    >
    > > $ configure --prefix=$HOME/units174
    > > bash: configure: command not found

    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > > $ ls -l configure
    > > -rwxr-xr-x 1 samantha samantha 55018 Aug 2 1999 configure
    > > $
    > >
    > > is this a specific instance where the ./ doesnt mean the same
    > > thing as it did in the mv file (if you were here for the last
    > > discussion there was confusion as to why I needed the ./ during
    > > a move (see previous post for full story)

    >
    > No, '/' is still the directory separator and '.' still means
    > *this* directory.
    >
    > That is your hint, actually. Obviously, the shell refuses to find
    > things that are *right here* in the current directory if you don't
    > prefix them with './'. The next question isn't ``what's this with
    > './'?'', but should instead be ``how does the shell do its finding?''
    >
    >
    > > now as far as I can figure out the ./ is needed to execute a
    > > shell script.. is this right?

    >
    > Nope. The key is ``find the program'', not ``is it a shellscript?''
    >
    >
    > [snip!]
    > > I always understood the . to mean "current directory" it doesn't seem to
    > > mean that in these instances. I have googled until my fingers are
    > > worn down trying to figure this out.

    >
    > Yes, it does.
    >
    > The shell reads your command and tries to figure out which one it is and
    > where to find it. The mechanism works by searching all directories in
    > the PATH environment variable[1]. Only. It doesn't look in the current
    > directory first. Why should it? If you want that, you can add . to the
    > search path.
    >
    > In fact, it turns out to be a really bad idea to add . to the search
    > path on multi-user machines, and even if you only ever use the machine
    > and nobody else is supposed to, it's still a bad idea. The why you can
    > figure out as an excercise.
    >
    > From that you can probably figure out why your configure command failed
    > and `units' seemed to work without `./' prefix. Hint: the program file
    > that was executed was not the one you thought was executed.
    >
    >
    > [1] Some shells vary a bit by keeping indices and so on. In general,
    > this is how it works.


    so when I used the ./units and I got the error, the program that I did
    the configure on and the make actually failed...

    well I did a

    $ ls -l /usr/bin/units

    and it spit out

    -r-xr-xr-x 1 root wheel 18644 Mar 20 2005 /usr/bin/units

    which means this is a common program and it was put on this machine back
    in 2005 by wheel ?? don't understand how that happened.. but okay..

    and the units that was i compiled in the ~/units174/bin directory
    actually failed to run because it couldn't find a file.

    well that leaves me to sort out the mystery of the failed compile.
    okay..

    I think I am getting a handle on this.. you think they would have
    mentioned that earlier in the execrcise.. this is a heck of a way to
    find out.

    BUT.. I DO THANK YOU FOR SORTING THIS OUT FOR ME.. I thought I was going
    mad for a moment.

    S.

  5. Re: The Period slash revisited...

    In article ,
    jellybean stonerfish wrote:

    > On Fri, 11 Jan 2008 00:25:38 -0600, Samantha wrote:
    >
    >
    > >
    > > $ ./configure --prefix=$HOME/units174
    > >
    > > well, I tried the configure without the ./ and it gave off an error
    > >
    > > $ configure --prefix=$HOME/units174
    > > bash: configure: command not found
    > > $ ls -l configure
    > > -rwxr-xr-x 1 samantha samantha 55018 Aug 2 1999 configure $
    > > is this a specific instance where the ./ doesnt mean the same thing as it
    > > did in the mv file (if you were here for the last discussion there was
    > > confusion as to why I needed the ./ during a move (see previous post for
    > > full story)

    >
    > > now as far as I can figure out the ./ is needed to execute a shell
    > > script.. is this right

    >
    > The first word of your input line is the name of the file to
    > execute. But your shell looks in only specific directories for commands.
    > If you type echo $PATH you will see what your path is. If a file with the
    > name configure is found in one of the directories in your path then the
    > file will execute if it is executable.
    > To tell the shell to run commands not in your PATH you must specify the
    > path. Such as ./configure or /home/fred/lesson/builddir/configure.
    >
    > For your ./units question, it looks like the script or program ./units
    > is trying to access /usr/local/share/units.dat and that file does not
    > exist. When you type units without the ./ it is running the units program
    > found in your PATH.
    >
    > If you want to see what file is really going to run when you type in a
    > command, such as ./units or units, you can use the which command.
    >
    > % which units
    >
    >
    > Does that help?
    >
    > stonerfish


    Yes that does help a great deal.. Thanks so much for answering my post.
    I think I am sorting it out now...

    S.

  6. Re: The Period slash revisited...

    Begin
    On Fri, 11 Jan 2008 07:48:07 -0600, Samantha wrote:
    [snip!]
    > so when I used the ./units and I got the error, the program that I did
    > the configure on and the make actually failed...
    >
    > well I did a
    >
    > $ ls -l /usr/bin/units
    >
    > and it spit out
    >
    > -r-xr-xr-x 1 root wheel 18644 Mar 20 2005 /usr/bin/units
    >
    > which means this is a common program and it was put on this machine back
    > in 2005 by wheel ?? don't understand how that happened.. but okay..


    units is indeed a common program, or at least it is on many systems.


    > and the units that was i compiled in the ~/units174/bin directory
    > actually failed to run because it couldn't find a file.


    Correct.


    > well that leaves me to sort out the mystery of the failed compile.
    > okay..


    It doesn't look like the compile as such failed. The program ran fine;
    it just decided it couldn't do what you expected without that file. The
    units in /usr/bin expects its file somewhere else[1], and does find it
    there. To change where your copy expects that file, set the appropriate
    configuration option to ./configure (that is one of the things configure
    does). Which option that is I'll leave as an excercise.


    > I think I am getting a handle on this.. you think they would have
    > mentioned that earlier in the execrcise.. this is a heck of a way to
    > find out.
    >
    > BUT.. I DO THANK YOU FOR SORTING THIS OUT FOR ME.. I thought I was going
    > mad for a moment.


    Unix is pretty short in its error messages --it is that way for a
    reason-- but it does mean you need to know something of its mechanics to
    understand what it is trying to say. Your tutorial might have assumed
    you already knew this, or, well, it forgot to mention. It too is written
    by humans, after all. :-)


    [1] See units(1) (IE, the manpage for units: `man 1 units') under the
    FILES section where it expects its standard units library file. At
    least my system does explain it there.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

+ Reply to Thread