On Fri, 31 Aug 2001, Clarence Verge wrote:
> > mc is great for a lot of things, but I don't really
> > recommend it for installing rpms when 'rpm -ivh' is
> > so easy.
>
> And difficult to remember. <g> Maybe that will change.
rpm = Redhat Package Manager
- i = install
- v = verbosely
- h = (show) hashes
You can do either of 'rpm -i -v -h <package name>' or
'rpm -ivh <package name>'
> How do you make (and launch) batch files in Linux ?
> Are they scripts ? If they are, please don't assume I know how to
> make them or where to put them.<G>
This isn't hard and fast, but usually a "program"
refers to a compiled binary while a "script" is a
series of commands in a file which will be interpreted
upon execution... of course, many scripts are referred
to as programs, so terminology in this case isn't to
be strictly relied upon.
You can write scripts in Linux in many languages.
For most of your "batch file" type operations you'll
most likely be using bash. You make a script with any
text editor. The key is to put the "shebang" on the
first line.
A shebang is a line that looks like this:
#! /bin/sh
The # is the "sh" and the ! is the "bang"
The # indicates a commented line not to be executed.
In the case of the shebang, the "comment" tells the
shell which interpreter will be used to execute the
lines following. In the case that your shell is
already bash (bash is compatible with sh), this shebang
could be considered redundant... however if you later
decide to use a different default shell, the shebang
insures your script will still work.
Here's a really simple script:
#! /bin/sh
for i in *.wav
do
echo $i
play $i
done
If you save this file as "playall" somewhere in your
path, then chmod it to be executable with
'chmod +x playall' then you can run 'playall' from any
directory. If there are no wave files, nothing will
happen. If there are, then it'll print the name of
the first one it finds and play it, then the second
and so on until it's listed and played them all.
Bash is much more powerful than batch files... as
a matter of fact, entire programs are written in
bash (remember when I said "program" isn't concretely
defined? ;-)
There are some excellent books on shell programming.
I have one, but it's still packed away, and I can't
recall the title offhand.
Failing a hardcopy, here are some beginning shell
tutorials:
http://linux.com/develop/newsitem.phtml?sid=64&aid=10910
http://www.linux.com/newsitem.phtml?sid=60&aid=9869
http://www.freeos.com/guides/lsst/index.htm
Where to put scripts:
If you want to execute them from all over, it's best
to put them somewhere in your path. The command 'env'
will show you your PATH among many other things, but if
you want to cut to the chase, you can do
'env | grep ^PATH'
(I've included /home/steve/bin in my path so I can
stow things there that I want to run... they could
just as easily go in /usr/bin, but since I backup
/home often, and /usr/bin rarely... ;-)
If the script is located anywhere outside your path,
you must type the entire path to it, i.e.,
$ /home/steve/office52/soffice
or first change to the directory where it's located
$ cd /home/steve/soffice52
and then still give the abbreviated path to it as
$ ./soffice
> > I see Steven has already given a pretty good answer,
> > (while I was away down south to NYC) so I'll add any
> > ..02 later on in the "thread."
>
> dmesg | grep eth0 comes up blank.
Yup, for me too (excepting firewall logged
packets).
> insmod <module for my card> ???
> How the heck I might know the module name for my card is beyond me.
When you buy a card, the instructions usually
tell you which module to use, and/or supply it.
For instance, my Netgear had a floppy with a tulip.c
driver optimized for that card, but also said that
any recent tulip driver would work.
> so I went to the Dlink disk and glory be -
> a Linux subdir.
>
> Arrrggghhh.
> The damn thing is a SOURCE file.
> This must be a conspiracy of some sort. Three years left to live
> and I spend time compiling code that would have been smaller, more
> friendly, and more error free if it was shipped in binary ?
Oh? Are you sure about that? ;-)
> Please don't tell me how nice it is that I can change the source -
> is it possible that someone could produce the binary for me from the
> source and makefile ?
I don't think so. As I understand it, each module is
linked against a certain kernel version. I'd be fairly
certain the module is already on your CD somewhere if
not installed on your hard drive.
Take a look in /lib/modules/<kernel version>/net/
and see if the <module>.o file that corresponds to
the source filename you found on the Dlink disk is
there.
> I loaded a lot of make and compiler crap and I'm getting nowhere fast.
> I didn't want to have anything to do with compiling "C" code before I
> started and I'm not any more excited about it now that I've wasted an
> hour trying to. <g>
With most source packages, if there's a configure
file, the process goes
$ ./configure
$ make
$ make install
If there's no configure file, (you might have
to manually alter the Makefile) you generally
just need to do
'make'
'make install'
- Steve
