concept of 'path' in linux - Help

This is a discussion on concept of 'path' in linux - Help ; hi - i'm sort of experimenting with linux. although i'm a bit of a coward, and run suse as a vmware machine, so far i like what i see.. i have some questions for you folks (concerning paths and installation): ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: concept of 'path' in linux

  1. concept of 'path' in linux

    hi -
    i'm sort of experimenting with linux. although i'm a bit of a coward, and
    run suse as a vmware machine, so far i like what i see..

    i have some questions for you folks (concerning paths and installation):
    - as a normal user all files i put in my /home/usr/bin are accessible from
    cmdline. correct? executable if permissions set correctly?
    - when i install something (using yast) an rpm - it gets installed somewhere
    on my drive (and it seems it is scattered across several directories) and
    often i can type: something at the cmdline, and it magically opens. is
    there an entry i can look for similar to the PATH variable in windows?

    - does there exist a win2linux transition guide somewhere? i'd like to
    understand the rationale behind the directory structure, runtime levels,
    although not on a developer's level.

    cheers,
    gp

  2. Re: concept of 'path' in linux

    GP wrote:

    > often i can type: something at the cmdline, and it magically opens. is
    > there an entry i can look for similar to the PATH variable in windows?


    mtobler@linux:~> cat .bashrc
    # Sample .bashrc for SuSE Linux
    # Copyright (c) SuSE GmbH Nuernberg

    # There are 3 different types of shells in bash: the login shell,
    # normal shell and interactive shell. Login shells read ~/.profile
    # and interactive shells read ~/.bashrc; in our setup, /etc/profile
    # sources ~/.bashrc - thus all settings made here will also take
    # effect in a login shell.
    #
    # NOTE: It is recommended to make language settings in ~/.profile
    # rather than # here, since multilingual X sessions would not work
    # properly if LANG is over-ridden in every subshell.
    ..
    --
    /// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
    \\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
    There is no TRUTH. There is no REALITY. There is no CONSISTENCY.
    There are no ABSOLUTE STATEMENTS I'm very probably wrong.


  3. Re: concept of 'path' in linux

    mjt wrote:

    > GP wrote:
    >
    >> often i can type: something at the cmdline, and it magically opens. is
    >> there an entry i can look for similar to the PATH variable in windows?

    >
    > mtobler@linux:~> cat .bashrc
    > # Sample .bashrc for SuSE Linux
    > # Copyright (c) SuSE GmbH Nuernberg
    >
    > # There are 3 different types of shells in bash: the login shell,
    > # normal shell and interactive shell. Login shells read ~/.profile
    > # and interactive shells read ~/.bashrc; in our setup, /etc/profile
    > # sources ~/.bashrc - thus all settings made here will also take
    > # effect in a login shell.
    > #
    > # NOTE: It is recommended to make language settings in ~/.profile
    > # rather than # here, since multilingual X sessions would not work
    > # properly if LANG is over-ridden in every subshell.
    > .

    OK. so my .profile/.bashrc files imports the settings in /etc/profile?
    And the following snippet from /etc/profile(i'm not too familiar with linux
    scripting) adds all subdirectories to path?


    for dir in /var/lib/dosemu \
    /usr/games \
    /opt/bin \
    /opt/gnome/bin \
    /opt/kde3/bin \
    /opt/kde2/bin \
    /opt/kde/bin \
    /usr/openwin/bin \
    /opt/cross/bin
    do
    test -d $dir && PATH=$PATH:$dir
    done


    then what is the deal with these rpms? is the difference between suse/rh
    rpms only that it 'dumps' the binaries into directories that are in the
    PATH variable? or is it more subtle? i'm guessing it is


    GP


  4. Re: concept of 'path' in linux

    GP wrote:

    > mjt wrote:
    >
    >> GP wrote:
    >>
    >>> often i can type: something at the cmdline, and it magically opens. is
    >>> there an entry i can look for similar to the PATH variable in windows?

    >>
    >> mtobler@linux:~> cat .bashrc
    >> # Sample .bashrc for SuSE Linux
    >> # Copyright (c) SuSE GmbH Nuernberg
    >>
    >> # There are 3 different types of shells in bash: the login shell,
    >> # normal shell and interactive shell. Login shells read ~/.profile
    >> # and interactive shells read ~/.bashrc; in our setup, /etc/profile
    >> # sources ~/.bashrc - thus all settings made here will also take
    >> # effect in a login shell.
    >> #
    >> # NOTE: It is recommended to make language settings in ~/.profile
    >> # rather than # here, since multilingual X sessions would not work
    >> # properly if LANG is over-ridden in every subshell.
    >> .

    > OK. so my .profile/.bashrc files imports the settings in /etc/profile?
    > And the following snippet from /etc/profile(i'm not too familiar with
    > linux scripting) adds all subdirectories to path?
    >
    >
    > for dir in /var/lib/dosemu \
    > /usr/games \
    > /opt/bin \
    > /opt/gnome/bin \
    > /opt/kde3/bin \
    > /opt/kde2/bin \
    > /opt/kde/bin \
    > /usr/openwin/bin \
    > /opt/cross/bin
    > do
    > test -d $dir && PATH=$PATH:$dir
    > done
    >

    >
    > then what is the deal with these rpms? is the difference between suse/rh
    > rpms only that it 'dumps' the binaries into directories that are in the
    > PATH variable? or is it more subtle? i'm guessing it is
    >
    >
    > GP


    Some changes in system RPM's (apart from the fact that the kernel/libs may
    be different, and this *can* affect the program) is that it will register
    the application in the KDE/GNOME/whatever application bar for you.

    E.g. Redhat puts applinks ofr KDE in a directory called applnk.redhat,
    whereas just about everyone else puts it in a directory called applnk.

    The LSB (Linux Standards Base) gives quite a bit of info on what should go
    where. Things like

    boot scripts in /sbin executables needed for boot scripts in /bin.
    User programs for command line in /usr/bin or /usr/local/bin
    Root programs for command line in /usr/sbin or /usr/local/sbin
    Directories with /local/ in the name should never be exported
    and so on.

    This keeps down the entries in the PATH, since the PATH needs to be parsed
    and searched each time you enter a command with no path given. A few dozen
    entries is OK, a few hunder is not.

    Advantage to PATH? You don't need a link that tells the program where it
    shoudl run from (as you do in Windows)
    Disadvantage to PATH? You have to check the executable goes in the right
    place (or use a symlink).

  5. Re: concept of 'path' in linux

    GP wrote:

    > hi -
    > i'm sort of experimenting with linux. although i'm a bit of a coward,
    > and run suse as a vmware machine, so far i like what i see..
    >
    > i have some questions for you folks (concerning paths and
    > installation): - as a normal user all files i put in my /home/usr/bin
    > are accessible from cmdline. correct? executable if permissions set
    > correctly? - when i install something (using yast) an rpm - it gets
    > installed somewhere on my drive (and it seems it is scattered across
    > several directories) and often i can type: something at the cmdline,
    > and it magically opens. is there an entry i can look for similar to
    > the PATH variable in windows?
    >
    > - does there exist a win2linux transition guide somewhere? i'd like to
    > understand the rationale behind the directory structure, runtime
    > levels, although not on a developer's level.
    >
    > cheers,
    > gp


    The placement of files in a linux or unix system is governed by the
    filesystem heirarchy standard.

    The Linux Filesystem Heirarchy Standard is fully set out in the Chapter
    35 of the Rute Users Tutorial and Exposition, a copy of which is in
    your installation disks. You can install this text using the Software
    Management tool in the Mandrake Control center (use search term rute)
    You should review this chapter.

    Under the standard, application executables would ordinarily go into
    /usr/bin or in /usr/local/bin, There are other parts of the tree for
    other types of executable, such as /bin or /sbin or /usr/sbin. Look up
    the differences in the standard.

    But a modern application is a complex of files of different sorts and
    kind, so while the executable file might be in /usr/bin/ its libraries
    would be in the /usr/lib tree and its documentation would be in the
    /usr/share tree and its configuration files in the /etc tree.

    Because each user will want to configure applications differently there
    are configuration or preferences directories in each user's home tree.
    For example, the Opera browser installs a hidden directory .opera in
    each user's home directory to hold that users bookmarks, skins and
    other preferences.
    The above is a gross oversimplification.
    It may look complicated at first, but the structure is a logical one and
    it does allow systems supervisors to know where to look for the files.

    As to the path:
    Open a terminal window and from a user prompt enter this command:

    echo $PATH

    it should return something like this:
    /usr//bin:/bin:/usr/bin::/usr/local/bin:/usr/X11R6/bin:/usr/games:/home/chdove/bin

    But if you switch to a root prompt by using the su command and entering
    your root password and then issue the same command, you will get
    something like this:
    /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin

    You can set the path temporarily using the PATH= command or the export
    PATH= command or you can permanently alter it by editing the path in a
    startup script. However, it is not a good idea to do so, for security
    reasons.





  6. Re: concept of 'path' in linux

    Clive Dove wrote:

    > GP wrote:
    >
    >> hi -
    >> i'm sort of experimenting with linux. although i'm a bit of a coward,
    >> and run suse as a vmware machine, so far i like what i see..
    >>
    >> i have some questions for you folks (concerning paths and
    >> installation): - as a normal user all files i put in my /home/usr/bin
    >> are accessible from cmdline. correct? executable if permissions set
    >> correctly? - when i install something (using yast) an rpm - it gets
    >> installed somewhere on my drive (and it seems it is scattered across
    >> several directories) and often i can type: something at the cmdline,
    >> and it magically opens. is there an entry i can look for similar to
    >> the PATH variable in windows?
    >>
    >> - does there exist a win2linux transition guide somewhere? i'd like to
    >> understand the rationale behind the directory structure, runtime
    >> levels, although not on a developer's level.
    >>
    >> cheers,
    >> gp

    >
    > The placement of files in a linux or unix system is governed by the
    > filesystem heirarchy standard.
    >
    > The Linux Filesystem Heirarchy Standard is fully set out in the Chapter
    > 35 of the Rute Users Tutorial and Exposition, a copy of which is in
    > your installation disks. You can install this text using the Software
    > Management tool in the Mandrake Control center (use search term rute)
    > You should review this chapter.
    >
    > Under the standard, application executables would ordinarily go into
    > /usr/bin or in /usr/local/bin, There are other parts of the tree for
    > other types of executable, such as /bin or /sbin or /usr/sbin. Look up
    > the differences in the standard.
    >
    > But a modern application is a complex of files of different sorts and
    > kind, so while the executable file might be in /usr/bin/ its libraries
    > would be in the /usr/lib tree and its documentation would be in the
    > /usr/share tree and its configuration files in the /etc tree.
    >
    > Because each user will want to configure applications differently there
    > are configuration or preferences directories in each user's home tree.
    > For example, the Opera browser installs a hidden directory .opera in
    > each user's home directory to hold that users bookmarks, skins and
    > other preferences.
    > The above is a gross oversimplification.
    > It may look complicated at first, but the structure is a logical one and
    > it does allow systems supervisors to know where to look for the files.
    >
    > As to the path:
    > Open a terminal window and from a user prompt enter this command:
    >
    > echo $PATH
    >
    > it should return something like this:
    > /usr//bin:/bin:/usr/bin::/usr/local/bin:/usr/X11R6/bin:/usr/games:/home

    chdove/bin
    >
    > But if you switch to a root prompt by using the su command and entering
    > your root password and then issue the same command, you will get
    > something like this:
    > /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local

    sbin
    >
    > You can set the path temporarily using the PATH= command or the export
    > PATH= command or you can permanently alter it by editing the path in a
    > startup script. However, it is not a good idea to do so, for security
    > reasons.


    Thanks for the reference - i'm using suse, not mandrake, but i found the
    rute-book online. I've only had time to look at ch35 - but i like it's
    style: begin rationale ... end rationale

    Also i've picked up 'running linux, 4th ed', hoping that it will ease the
    transition.

    As said - thanks for the info. Now i have to do some tinkering/studying..

    GP


  7. Re: concept of 'path' in linux

    GP wrote:

    > Clive Dove wrote:
    >
    >> GP wrote:
    >>
    >>> hi -
    >>> i'm sort of experimenting with linux. although i'm a bit of a
    >>> coward, and run suse as a vmware machine, so far i like what i see..
    >>>
    >>> i have some questions for you folks (concerning paths and
    >>> installation): - as a normal user all files i put in my
    >>> /home/usr/bin are accessible from cmdline. correct? executable if
    >>> permissions set correctly? - when i install something (using yast)
    >>> an rpm - it gets installed somewhere on my drive (and it seems it is
    >>> scattered across several directories) and often i can type:
    >>> something at the cmdline, and it magically opens. is there an entry
    >>> i can look for similar to the PATH variable in windows?
    >>>
    >>> - does there exist a win2linux transition guide somewhere? i'd like
    >>> to understand the rationale behind the directory structure, runtime
    >>> levels, although not on a developer's level.
    >>>
    >>> cheers,
    >>> gp

    >>
    >> The placement of files in a linux or unix system is governed by the
    >> filesystem heirarchy standard.
    >>
    >> The Linux Filesystem Heirarchy Standard is fully set out in the
    >> Chapter 35 of the Rute Users Tutorial and Exposition, a copy of which
    >> is in
    >> your installation disks. You can install this text using the
    >> Software Management tool in the Mandrake Control center (use search
    >> term rute) You should review this chapter.
    >>
    >> Under the standard, application executables would ordinarily go into
    >> /usr/bin or in /usr/local/bin, There are other parts of the tree for
    >> other types of executable, such as /bin or /sbin or /usr/sbin. Look
    >> up the differences in the standard.
    >>
    >> But a modern application is a complex of files of different sorts and
    >> kind, so while the executable file might be in /usr/bin/ its
    >> libraries would be in the /usr/lib tree and its documentation would
    >> be in the /usr/share tree and its configuration files in the /etc
    >> tree.
    >>
    >> Because each user will want to configure applications differently
    >> there are configuration or preferences directories in each user's
    >> home tree. For example, the Opera browser installs a hidden directory
    >> .opera in each user's home directory to hold that users bookmarks,
    >> skins and other preferences.
    >> The above is a gross oversimplification.
    >> It may look complicated at first, but the structure is a logical one
    >> and it does allow systems supervisors to know where to look for the
    >> files.
    >>
    >> As to the path:
    >> Open a terminal window and from a user prompt enter this command:
    >>
    >> echo $PATH
    >>
    >> it should return something like this:
    >>

    /usr//bin:/bin:/usr/bin::/usr/local/bin:/usr/X11R6/bin:/usr/games:/home
    > chdove/bin
    >>
    >> But if you switch to a root prompt by using the su command and
    >> entering your root password and then issue the same command, you will
    >> get something like this:
    >>

    /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local
    > sbin
    >>
    >> You can set the path temporarily using the PATH= command or the
    >> export PATH= command or you can permanently alter it by editing the
    >> path in a
    >> startup script. However, it is not a good idea to do so, for
    >> security reasons.

    >
    > Thanks for the reference - i'm using suse, not mandrake, but i found
    > the rute-book online. I've only had time to look at ch35 - but i like
    > it's style: begin rationale ... end rationale
    >
    > Also i've picked up 'running linux, 4th ed', hoping that it will ease
    > the transition.
    >
    > As said - thanks for the info. Now i have to do some
    > tinkering/studying..
    >
    > GP


    Both of those books are excellent reference sources, although the Rute
    one is more of a textbook. I do suggest that you get the Rute Users
    Tutorial and Exposition in its paper form, possibly from Chapters or
    Barnes & Noble or Amazon, as the book is over 600 pages. My copy of
    both books are well thumbed.

    Clive



  8. Re: concept of 'path' in linux

    GP wrote in message news:...
    > Clive Dove wrote:
    >
    > > GP wrote:
    > >
    > >> hi -
    > >> i'm sort of experimenting with linux. although i'm a bit of a coward,
    > >> and run suse as a vmware machine, so far i like what i see..
    > >>
    > >> i have some questions for you folks (concerning paths and
    > >> installation): - as a normal user all files i put in my /home/usr/bin
    > >> are accessible from cmdline. correct?


    Correct. From any directory you could type /home/usr/bin/application
    to run application.

    > >> executable if permissions set
    > >> correctly?


    Indeed

    > >> - when i install something (using yast) an rpm - it gets
    > >> installed somewhere on my drive (and it seems it is scattered across
    > >> several directories) and often i can type: something at the cmdline,
    > >> and it magically opens. is there an entry i can look for similar to
    > >> the PATH variable in windows?[snip]


    Yup, its called PATH. "echo $PATH" will show you your current PATH.
    (assuming bash shell) Your .bash_login will contain personal scripts,
    usually including additional PATH information. The global /etc/profile
    also usually contains PATH information, but for each and every user.

    The "env" command will show you a list of other environment variables.

    You can set one like this "export NEWVAR=1".

  9. Re: concept of 'path' in linux

    Mark Hackett wrote:
    > Some changes in system RPM's (apart from the fact that the kernel/libs may
    > be different, and this *can* affect the program) is that it will register
    > the application in the KDE/GNOME/whatever application bar for you.


    Mmmkay. Specifically what libs do you mean? Core libs like glibc? Does this
    mean that it's not safe to assume that rpms for the most recent rh distro
    work for suse9?

    GP

  10. Re: concept of 'path' in linux

    GP wrote:

    > Mark Hackett wrote:
    >> Some changes in system RPM's (apart from the fact that the kernel/libs
    >> may be different, and this *can* affect the program) is that it will
    >> register the application in the KDE/GNOME/whatever application bar for
    >> you.

    >
    > Mmmkay. Specifically what libs do you mean? Core libs like glibc? Does
    > this mean that it's not safe to assume that rpms for the most recent rh
    > distro work for suse9?
    >
    > GP


    Often there are necessary changes in the kernel (Mandrake change it to allow
    supermount, SUSE have backported some kernel 2.6 code to their 2.4), and
    that can change the interface to the central kernel code on that system.

    Also some bugs can be found in glibc (or at leas with how the glibc works
    withg the changes above...).

    It's usually a good idea to stay with binary RPM's for the distribution you
    have, or compile from source. You can normally install Mandrake RPMS on
    SUSE (for example), but you may get more faults that way. Dpendency
    problems will often ocurr if you use the wrong distro-specific RPM (RedHat,
    IMNSHO, are the worst for the - "this lib requred version >1.1, you have
    version 1.1.4. Unable to continue".... Grrr).

    So the answer for your question is "it depends". If you cannot find either
    source or a SUSE-specific RPM, take more care when installing the RPM. If
    it goes in without needing any weird flags (I.e. "rpm -Uvh "
    works, then you are almost definitely OK. If you need to use "--force",
    then you should expect some problems later on. Yo uwill probably be OK, but
    it's better to assume the worst, then you an only be pleasnatly suprised!

    Ta.

+ Reply to Thread