Hey thanks Paul... that was alot of useful info. I will definately look into the path and
the process info up in more detail. I didn't know about that before, but now I'll look
into it more.
I've learned more about linux in 3 days than I have in the last 3 years of playing with
it. My learning curve is almost vertical right now. The slug mtg. in Dunedin was a huge
motivator... thanks guys. I'll come to next months mtg. loaded with my laptop and lotsa
questions...
thanks to everyone who responded to my question! You guys should collaborate and write a
manual! You're explainations were better than any book I've tried to read so far.
Eric
> On Tue, May 27, 2003 at 06:48:48PM +0000, lugmail@tampabay.rr.com wrote:
>
> > I'm fairly new to linux, but very comfortable at a command line, and I'm
> > in need
> > of help with some commands, so thanks in advance to all who respond.
> >
> > I have both a Mandrake 9.1 and RedHat 9.0 install that I'm playing with. I'm
> > trying to install the Java SDK and the Sun One Studio on either of these
> > installs, I don't care which. The Sun One Studio is a .bin file. There is
> > little to no installation instruction on the java home page for installing
> > this
> > to linux. They reference a chmod command (chmod a+x <filename>), but that
> > didn't work.
>
> The above command makes the file executable for everyone. There are
> owner, group and world permissions on files in Linux/Unix, and you're
> setting the executable bit for all three type of permission. Keep in
> mind that, depending on who the file is owned by, you may not be able to
> change its permissions. If you're root, or you own the file, you can
> change its permissions; otherwise not.
>
> >
> > A couple of questions...
> >
> > 1. Where would one normally install programs on a linux box? For instance,
> > in
> > windows (no comments from the peanut gallery please), most installs
> > default to
> > somewhere under c:\program files. Where do we put linux installs and why??
> > Are
> > there common standards for where we install stuff to?
> >
>
> The distribution itself will install executable files in /bin, /sbin,
> /usr/bin or /usr/sbin. Anything you install should go in either
> /usr/local/bin or /opt (the former is preferable).
>
> > 2. What do I do with .bin files? Do I just type the filename at the command
> > line? I've tried that, but nothing happens. I've also tried chmod and
> > when I
> > do an ls it changes color and puts an asterisk after the filename, then
> > I tried
> > the filename by itself and nothing. What does the asterisk mean?
> >
>
> Understand that under Windows, the extension of a filename provides the
> key to what type of file it is. That's not necessarily true under
> Linux/Unix. Most likely, what you have there is a binary file
> (executable), but it's hard to say. In order to find out, do this:
>
> file <filename>
>
> This will tell you what type of file it is. If it says something about
> "ELF", then it's a Linux-ready executable. Otherwise, it may or may not
> be executable, depending on what the "file" command returns.
>
> > I've been logged in as root and as a normal user. I've tried it in my home
> > directory and copied to several other directories, to no avail.
>
> Some info on "paths" under Linux. There is a path statement in
> DOS/Windows, usually in your autoexec.bat, which is something like this:
>
> PATH=c:\;c:\windows
>
> There is a similar thing in Linux, but in a different file with
> different syntax. You can run this command to see what your path is:
>
> echo $PATH
>
> This path will vary depending on your userid. If you're root, it may be
> one thing; as a regular user it may be something else. Also note that
> the directory delimiter is a semicolon under DOS (;), but under Linux,
> it's a colon (:).
>
> The path in Linux specifies where Linux will look for executables if you
> simply type a command (like: ls -l). There is a significant difference
> between Windows and Linux in this respect, though. Under DOS/Windows,
> there is an "understood" addition to your path that includes the current
> directory. That is, if you type the name of a command that's in your
> current directory, even if that directory is not in your path, the
> command will run. This isn't true in Linux. In Linux, the path is
> exactly what you see, and doesn't normally include the current
> directory. You can get around this (and run a command in your current
> directory) by preceding the command name with ./ as in:
>
> ../my_executable
>
> Now, assuming that you manage to actually "run" the .bin file you
> mentioned earlier and nothing happens, then you're stuck. If it's not
> going to run, then it _ought_ to issue some warning or some instructions
> or something. If not, you may have to go back to Sun.
>
> There's another possibility. It could be that running the executable
> starts a "daemon". A daemon is a program that runs in the background.
> Many programs start daemons and you'd never know they're running (like
> Apache). You can find out if that program is running in the background
> by doing the following:
>
> ps ax | less
>
> What you'll be looking at is the "process table" that indicates what all
> is running on your machine. You can page up and down and examine what's
> going on. If you see the name of your file in there, then it's running
> a daemon. If you happen to see more than one of these, then you may have
> a situation where they are all blocking each other, and you need to
> "kill" them to start over. When you look at the output of the ps
> command, you'll see in the left hand column a number. That number is the
> process ID or PID of the process. If you want to kill something, you
> issue the following command:
>
> kill <process_id>
>
> If it won't die (sometimes they won't), then issue:
>
> kill -9 <process_id>
>
> Use this sparingly, as it's like using a shotgun to kill a roach.
>
> (BTW, I know nothing about installing and running Java. I'm just
> speaking here in very general terms. Even if this don't help you on this
> particular problem, maybe it will assist on something else.)
>
> Paul
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:23:19 EDT