On 3/25/2010 6:03 AM, Johan wrote:
On 03/25/2010 09:42 AM, Per Jessen wrote:
Johan wrote:
good day,
Lazarus the following in command line..
johan@linux-v2bn:~/allprograms/Numerology/core-numbers2> . corenumbers2 If 'ELF' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf ELF johan@linux-v2bn:~/allprograms/Numerology/core-numbers2>
In free pascal it is like this...
johan@linux-v2bn:~/allprograms/pascalprograms> . addition If 'ELF' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf ELF
Johan, try this instead:
./addition
Well I'll be .....??
Easy just one char added and all is well.
Funny scripts do work without the /
No they don't, at least they don't do what you think they are doing that way. In a bourne shell interpreter, which is what you are in while you are logged in and sitting at a command prompt, the syntax "dot space filename" does not execute the file, it sources the file. That means it reads the file and pretends that you typed in it's contents at the prompt you are sitting at. It has the effect that your current shell instance ends up directly executing the commands, which may look and smell like the normal way a script or program is executed, but it's in fact quite different. Sourcing a file is usually meant for a script to read in some variables from another file and have those variables set in the current shells environment. So for one example, 10 different scripts could all read the same set of settings from a single file, so you could have one file with settings in it and 10 scripts that each just sourced the settings file. Where otherwise you'd have to write those variables in 10 different scripts, and remember to change them all later when something needs to change. But it works for any valid shell commands not just setting variables and that has many uses in special situations. You can define a whole function or performs all kinds of programming logic to set variables dynamically etc. You do not use the sourcing mechanism simply to run shell scripts. You run them the same way you'd run any other kind of executable. If you tried to source a binary or a perl script it would not work (as you found out) and might not be harmless in the way it failed either (as you were lucky enough this time not to find out). The simplest example of why this is "wrong" even though it seems to "work for scripts" would be to look at any typical script that has an exit command. #!/bin/sh echo "Hello there, I'm going away now." exit If you run that script any of the proper ways, by making it executable and executing it, or by executing "sh" and giving this scripts filename as a commandline argument to sh, example: chmod 755 hello ./hello or sh hello Then it does what you'd expect. It prints the message and your prompt is returned. If you source this script instead, example: . hello It would print the message and immediately log you off the system or close the xterm you were using. The difference is, when you run a program, be it a binary or a perl script or shell script or other, it runs in a new process which is a child of your shell process (your command prompt). The exit command in the script just causes the child process to die, and control returns to your shell and you get a new prompt. That's normal. Every program has an exit somewhere. It's often omitted from scripts because once there is no more script file to read the shell will exit by itself as if there had been an exit command. If it didn't do that it'd just hang there forever. When you source a file, your _current_ shell process interprets the commands itself directly, no child process. When it reaches that exit, it's exactly the same as if you typed exit and hit enter, which closes your window or logs you off the system, depending on how your are connected. It's also wrong because script authors know that the script is running in it's own new child environment which is destroyed at the end, so they are free to do almost anything, including setting environment variables, cd-ing to other directories, changing the shells behaviour, because none of that will affect the parent process that ran the script. A script might cd to /tmp, disable filename globbing, and change the LOGNAME or USER or LANG environment variables to suit the needs of whatever task it's doing. If you source that script instead of run it, your current login shell is modified with all those changes, which will screw up everything you try to do from that point on until you log off and log back in. -- bkw
Thanks. May you have a nice day. Regards Johan Sch
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org