Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

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.

This has to be an environment problem. It could be that the environment isn't being inherited by the script; in which case, check that you own the file. From the bash manpage:

Quote:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS variable, if it appears in the environment, is ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

You could also try adding -p to the shebang line in this case (though I haven't tried this)
(Edit: The shebang line is the one that starts with #!)

Uff, I found out what the problem was...
I created the shell script in Windows using Eclipse.
This was the version which didn't work. Then,
on my Linux box, I played a bit around with the
kedit editor, as I found by accident, that when I
remove the first CR/LF and re-add it in kedit, the
shell script works!

I can remember exactly, but what was the difference
between Win and iX? iX has <CR> only and Win has <CR><LF>?
Or was it vice versa? Anyway, this is funny behavior...
Does anyone know about this?

Macs do indeed use <CR> (though not sure now that Mac OS X has a BSD core).

I'm going by what I read a while ago but I think it comes from old teletype machiens etc. that were sending messages over telephone wires (similar to FAX machines). The <LF> stands for Line Feed and returns the location of the next character down a line. A separate command would return the cursor to the beginning of the line. <CR> on the other hand does both in one sweep. However, when computers where still maturing different operating systems used either one or the other. MS Windows went for including both just to be sure even though it makes little sense.

Please take this with a pinch of salt since I haven't read up on this for a while. Unfortunately this old over throw of the old days of computers still comes up and bites us in the backside. I usually notice it when move a Linux text file to Windows. Windows will just display it as one solid line of text with a little box to denote where the <LF>'s are.