Some questions about using scripts

[LNSmith]

Hello all:

I am learning how to use scripts in uPupBB (32 bit).

I have some basic questions about script location and where scripts should be located.

I wrote a simple script and it worked - but only when I placed the script - "script_z" in the directory called /root/my-applications/bin
That directory is in the variable $PATH.
Check:
# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games


Now my questions.

Q1. In Puppy Linux is the directory /root/my-applications/bin the 'proper' location for saving/storing scripts?
Yes?
No? If 'no' then where, pls?

Q2 I moved the script up one level (fr. /root/my-applications/bin) to /root/my-applications.
I changed directory (cd) to /root/my-applications.

I confirmed that - using pwd.
When I ran that script (from the terminal command line interpreter) I got a message: bash: script_z command not found.

--> My question: I assume that Linux is set up so that the present working directory IS NOT SEARCHED FOR A SCRIPT. Yes? No?
If 'yes' why did the script not run?

Comment: When my pwd is /root/my-applications and script_z IS IN THAT DIRECTORY I can run the script using: bash script_z.

To all who answer my simple Qs: Thank you.
All the best from New South Wales, where every-one is living a solitary (and woofy) existence. - Leslie

[nic007]

You can run a script from any location. It should work if you right-click the script > choose permissions from righ-click menu and make it executable (the top option in the options window).

[MochiMoppel]

--> My question: I assume that Linux is set up so that the present working directory IS NOT SEARCHED FOR A SCRIPT. Yes? No?

Yes

If 'yes' why did the script not run?

well, you said it already: because is is set up so that the present working directory IS NOT (automatically) SEARCHED FOR A SCRIPT.
The PWD is only searched if the PWP also happens to be in the PATH, which in your case it is not
Your PATH contains /root/my-applications/bin but not /root/my-applications, 2 different directories.

[enrique]

Linux comes from Unix. Unix and even Linux had its Rules. I say this because at any moment someone may tell you to follow a rule.

The best rule I learn is "Keep it simple". Now you are learning so take it easy.

You can run a script from any location...

100% true. What is missing is that in Linux you need to specify the path.

Read this

Code: Select all

https://www.tutorialspoint.com/unix/unix-directories.htm

Lets resume.
Where you can run your scripts?
**Any ware

Where is the smart area to do it?
**While learning keep it in your home dir.

Where is your home dir?

Code: Select all

echo $HOME

What if I do not want to add path?
**Well you answer that, place in /root/my-applications/bin

...--> My question: I assume that Linux is set up so that the present working directory IS NOT SEARCHED FOR A SCRIPT. Yes? No?

**NO is not true. what hapens is that in Linux you have to specify the path

...If 'yes' why did the script not run?

**Again because you did not specify the path

...When my pwd is /root/my-applications and script_z IS IN THAT DIRECTORY I can run the script using: bash script_z.

** I know at last the answer you where looking.
In order to execute a script in the same folder we are, you need to use "." = (dot) represents the current working directory

So the answer is

Code: Select all

./script_z

[MochiMoppel]

Where is the smart area to do it?
**While learning keep it in your home dir.

Why?

[nic007]

You can move or copy it to a new location and if it does not run, set the permissions again from the new location as mentioned. I may be wrong though... although all my scripts (the same ones) run from different locations without a problem.

[jafadmin]

If you want it to run from a command prompt, put it somewhere in the $PATH

If you want to run it by clicking it with your mouse, put it anywhere.

"/usr/local/bin" and "/root/my-applications/bin" are my usual spots.

.

[bigpup]

The Linux file system is explained here:
http://www.dummies.com/how-to/content/l ... asics.html

This is a guide only as to where to put stuff.
It is really up to you, but this is the places to kind of keep stuff organized.

# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games

The idea behind PATH

PATH Definition. PATH is an environmental variable in Linux and other Unix-like operating systems that tells the shell which directories to search for executable files (i.e., ready-to-run programs) in response to commands issued by a user.

If an executable is in a PATH location.
only command needed is the name of the executable.
If not in a PATH location.
You have to give the location info and the name of the executable.

[williams2]

Also, you can run most scripts anywhere, without needing to set any permissions, and you do not need a special line at the top like #!/bin/sh and you do not need to use ./

For example, you could start a console text terminal
and use geany to create a script named "hello"
and if you type "echo hello puppy" in the script and save it,
then you can run it like this:

Code: Select all

geany hello
cat hello
echo hello puppy
sh hello
hello puppy
mv hello /tmp/
sh /tmp/hello
hello puppy

and like this: python rename-files.py
or: newlisp myscript.lsp

If you need to change permissions of a file or dir,
any easy way is to right click the file and click Properties
Usually you want all 3 executable boxes checked. (the right column)

[MochiMoppel]

Also, you can run most scripts anywhere, without needing to set any permissions, and you do not need a special line at the top like #!/bin/sh

Even if in this case a shebang isn't required it would still be a good idea to always use one. Enables syntax highlighting, e.g in Geany, and displays a script icon in ROX-Filer.

[williams2]

Even if in this case a shebang isn't required it would still be a good idea to always use one.

Yes, absolutely correct.

And when I said, "without needing to set any permissions", I should have said, and meant to say:
"without needing to set execute permissions"
because if permission to read the file is disabled, it will not execute.

[enrique]

Where is the smart area to do it?
**While learning keep it in your home dir.

Why?

Why? Because if you start writing stuff all around the Linux file system chances are than in 1 week, 1 month or 1 year you will not remember what are those files or where you put them. Now honestly it does not have to be in your Home directory, that was the original Linux idea. Just create a work place any where you like. Then use that location always. In the future you will remember those files are yours.

Did you remember what I say:

... I say this because at any moment someone may tell you to follow a rule.

1rst I should had added "Or Not to follow a Rule".

In the past posts, there are stuff that seems to contradict. In Linux there is always 100 of ways to do same thing. And every one has its opinion. That is why I also say:

The best rule I learn is "Keep it simple". Now you are learning so take it easy.

Enjoy the forum. Have fun.
Long live Puppy Linux

enrique

[ras]

Q1. In Puppy Linux is the directory /root/my-applications/bin the 'proper' location for saving/storing scripts?

A "proper" vs "convenience" question for all.

For convenience, I have traditionally kept scripts in the user directory (/root with pups) , as they do not get missplaced as easily when I migrate to a new install.

However, I find more and more, that I keep much that used to be kept in /root, outside the the savefile so I can utilize multiple puppies with the same configs etc. Typically this means a higher level directory, then creating links back to /root.

From years back, I seem to recall some advice to not put user created scripts in a place where another could execute. Are there similar concerns I might not have remembered that would make keeping my own scripts outside the user directory a poor practice?

Edit: perhaps the dimly remembered advice was to not arbitrarily add directories to the PATH. Some hierarchical logic to the path statement?

Leslie, if this post is too off topic, please let me know.

[Mike Walsh]

I concur with what most of you guys have already stated.

If I understand it correctly, part of the reason for the $PATH protocol is to simplify the writing of scripts, .desktop entries, tons of other scripts/files in multiple other locations. Be that as it may, whenever modifiying or creating new applications, scrits, Menu entries, whatever, I tend to prefer to specify full PATHs. Always.

I know it's not 'the Linux way', but it's my way. And it always works for me.

@ Les:-

As Nic has stated, you can run scripts from anywhere. I have done for years, and it's greatly aided by the Linux 'principle' that everything is simply a 'file', regardless of where it's located, what its function is or what it actually does/is used for. However, essentially, Puppy $PATH locations can be summed-up as :-

/root/my-applications/bin - this one's a Puppy 'special', TBH. 'Standard' locations will include multiple locations within the '/usr' directory, e.g:-

/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin - as far as I'm aware, this last one doesn't always seem to exist; sometimes you may need to create it if you feel you need it.

Have a good read of bigpup's link; the sooner you understand the functioning of the Linux file-system, and why it is that things are put where they are, the stronger a position you'll be in to start creating your own apps/utilities, etc......and the sense of satisfaction you get from creating something for your own use, that does exactly what you want it to do, is unparalleled IMO.

(Always aim for functionality first. 'Frills' - appearance, other little 'extras' - can come later, once you get the thing's operation working properly.)

Hope that helps.


Mike.

[tallboy]

LNSmith, you can place a script anywhere, and make a link from it to any directory in the PATH, which you'll find if you follow bigpup's recipe above.

As an example, the script that starts Palemoon, is usually a symlink from the binary /opt/palemoon/palemoon, to /usr/bin/palemoon, which is called upon from /usr/local/bin/defultbrowser.