SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Originally posted by munkie_poo ooooh.. its done something
: bad interpreter: No such file or directory
will this be a problem with the script?
Very probably. Most scripts begin with the sequence "#!<some_program_name>" (for some reason, it's called a "shebang" ...). For example: "#!/bin/sh". This is supposed to specify the program that is to be invoked to "run" this script; in this case, "/bin/sh." Perhaps that program does not exist, or the file is not marked "executable."
As you have seen, if you try to execute a file and the "x" permission-bit is not on (see chmod), you get a cryptic "permission denied" message. Now that you have turned-on this permission, the shell might be looking at the shebang and is trying, unsuccessfully, to invoke that interpreter-program. Just a guess, but a good one...
Make sure your drive is mounted with exec priveleges (?). For example, this is what my mount command produces. Note that /dev/hdb2 is noexec. That means I won't be able to run a script from there. You can change this by modifying the options in fstab.
/dev/hda2 on / type reiserfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)
/dev/hda4 on /home type reiserfs (rw)
/dev/hda5 on /media type reiserfs (rw)
/dev/hda6 on /asdf type reiserfs (rw)
/dev/hdb1 on /x type reiserfs (rw)
/dev/hdb2 on /mnt/media type reiserfs (rw,noexec,nosuid,nodev)
none on /proc/bus/usb type usbfs (rw)
Distribution: Slackware 11.0; Kubuntu 6.06; OpenBSD 4.0; OS X 10.4.10
The ./ is important. If it is omitted, your shell will search your $PATH variable to find the application "configure". It is unlikely that it will find one, unless you have "." in your $PATH variable. If it does find one, and "." is not in your $PATH variable, the one it finds will in all probability not be the one you want. Whenever you are compiling, it is a good idea, sometimes even required, to use the ./.
BTW, there is a school of thought that says that putting "." in your path is a bad thing for security reasons. I think that is probably true for root. For a normal user, it probably isn't as bad. Just for the record, I have "." in my $PATH.