Re: [SLUG] Need help with .bin files!

From: Paul M Foster (paulf@quillandmouse.com)
Date: Wed May 28 2003 - 18:53:36 EDT


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:22:36 EDT