Standard operating practice - bash scripts

[cobaka]

Hello all!
My 'Q': In puppy Linux, what directory is normally used to save my own bash script files?

Background: #when I type $PATH Puppy responds with:
bash: /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games: No such file or directory

In particular should scripts be stored in 'my-applications' or 'my-applications/bin'?
The reason for my confusion comes because I believe 'bin' directories were reserved for binary (executable) files.
In my mind a script file is not a binary file. It is a script file, but (at some stage) I put some scripts in 'bin'.
Maybe, by convention, a script is considered to be an 'executable' while it is clearly ascii (or perhaps UTF-8) text.
Certainly not code.

Yes, my Q is trivial. A script will run from 'my-applications' or my-applications/bin.
But I'm a beginner and I want to avoid problems in the future by using standard procedures from the beginning.

One last Q: Why do I see the message "no such file or directory".
I don't remember this error message before.

cobaka

[taersh]

For scripts I use mostly /usr/sbin = script binary or I put them into a sub-directory in /usr/local. The /usr/local/bin is also mostly used for scripts. All the defaultXXX scripts are stored in e.g. /usr/local/bin.

If there's a message "no such file or directory" that means a program or script running did not find a file or directory needed/used. Usually this message appears in a terminal only. Never seen this anywhere else.

[cobaka]

@taersh
Thank you for your reply. (Very prompt!)
I see I have the directories you mention but there are many scripts in there.
I want to keep my scripts separate from system scripts (Don't want to clobber a system script, do I?)

What practice should I use to keep my scripts in the same directory as the system scripts and avoid clobbering 'good stuff'?
Should I create a 'group' called 'script-group' (or something) so I can maintain back-ups & so on?


As for the fault message, 'No such file ...' I see the msg when I type '$PATH'. (no quotes).
As I understand: $PATH is the name of a linux variable.
Why do I get an error when I type the name of a variable?

cobaka

# $PATH
bash: /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games: No such file or directory

[mikewalsh]

@ Leslie:-

In large part, this is going to depend on whether you're going to be a good, obedient little "Linuxian" and follow all the pre-determined rules for how Linux should work, right down to the letter......including using all the correct locations for things, writing everything the correct, "proper" way, constructing stuff according to long laid-down, "accepted" methods, etc, etc.

Or, if you're like me, you bend the rules a bit - well; sometimes, a LOT! - and instead of always using the pre-determined system 'paths', you sometimes stick things in slightly unconventional locations & use absolute paths to 'point' to everything instead.

There's no hard & fast rules in Linux, especially not here in Puppyland.....where I think we have a bit more freedom to bend the rules than most! If you remember ONE thing, you won't go far wrong; it doesn't matter where each & every individual file goes, just make sure that if you're not using accepted system paths, then make certain you use absolute 'pointers' instead, so that every part of your app, program, whatever, is able to find every other part that it needs to function.

I could write a book about all the workarounds & dodges I've made use of over the years, but it would take way too long to go into all that now.

----------------------------------------------------------

As far as binaries & scripts are concerned, well, no.....a script is NOT a binary, you're right in that respect. But a script can be made to execute in the same way as a binary. And in a nutshell, this is the thing about all the various 'bin' directories; they're not exclusively for 'binaries', but they ARE intended to be for executable files.....remember, under Linux, everything is a file; a script, a binary executable, a dynamic linked library, a database, a text file, a kernel module.....to the OS, they're all treated in many of the same ways.

Essentially,

- /bin of any kind is global binaries
- /sbin of any kind is system binaries
- /usr/local/bin is generally for personal scripts, etc

- /root/my-applications/bin is a Puppy 'special'; unique to Puppy, you won't find this anywhere else.....but it IS included in the

Code: Select all

$PATH

.....command, as you've seen for yourself. These are set in the first couple of lines of the text file at /etc/profile.

You can't learn all this stuff overnight. I was always keen to contribute stuff back to the community, after all the help I got in my own early days, but no matter how "keen" you are, and how much time you spend on this stuff every day, it takes months, even years, for it all to come together. Practice makes perfect; we learn from our mistakes, and you're constantly picking up wee tips & tricks as time goes by. It's a continuous learning process, and there's always a slightly better or improved way of doing something, somewhere along the line. And with Linux being as flexible as it is - scripts being responsible for a lot of that flexibility - there's often dozens of ways of achieving the same outcome. But sometimes one method will work better, where on a separate occasion, another method will provide a more satisfactory outcome.

Don't be disheartened, mate. You're currently at the stage I was at myself, getting-on for nearly 5 years ago.....been a lot of water under the bridge since then..! Just make sure to be flexible yourself, and remain open-minded.....and above all else, remember to have fun with it.

Puppy's all about having fun. Remember that, as well!


Mike.

[taersh]

Hi.

When I joined the old forum I made a very cool Puppy version which was called "LazY Puppy". To avoid conflicts on my scripts with existing ones or later ones I started to name my scripts e.g. lazy_sfs_load (so it wouldn't conflict with the original sfs_load script). Later I used the first characters of my full name e.g. rsh_script_name etc.pp.

When I'm typing $PATH into a terminal it returns /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games. Can't say why yours is different.

Could you post a screenshot of terminal output of $PATH?

[cobaka]

@cobaka

Ha! I have it! The shell is powerful. Very powerful, but to use it demands precision.
When I type: # echo $PATH, (no comma) there is no error. Silly me!
I'm learning ... (slowly)

cobaka.

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

[taersh]

I don't need to type echo $PATH!
Just $PATH is working.

Screenshot.png (14.46 KiB) Viewed 2184 times

[cobaka]

@mikewalsh
@taersh

Thanks to both of you for your help and encouragement.

On the topic of $PATH:
$PATH is a variable not a command.
echo is a command.
This is what I figure: When I type at the CLI (the command-line interpreter/the shell) I must precede the name of a variable by a command.

IF I give the command: echo $PATH THEN Linux responds predictably ELSE I get a syntax error ENDIF ;

# $PATH
bash: /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games: No such file or directory

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

I'm using uPupBB32 - the busy beaver Pup.
I have been using uPupBB for about 8 months now (seriously using. bash+grep/sed/awk and so on).
I'm still a novice, but I know two things: Puppy Linux is very reliable and very easy to recover 'when the wheels fall off.' (2) I can do things from the shell in a few hours that would take me days in a windowing environment.

@mikewalsh
Thank you, mike, for your words about directories/folders. I'll read very carefully and consider the implication.
In my mind, fun comes from learning the discipline of developing a standard method.
When we (users) adopt a standard working practice, then the time spent chasing bugs and maintaining the system becomes less.
That's why I want to work according to recognized practice.

Again, tnx fer ur hlp.

cobaka.

[taersh]

Ok, I see.

I did understand that the way you will get the error message only. Without the paths being echoed. That message is also in my output: "Datei oder Verzeichnis nicht gefunden". So everything is fine. Just a misunderstanding.

[mikewalsh]

I don't need to type echo $PATH!
Just $PATH is working.

.....but doesn't "Datei oder Verzeichnis nicht gefunden" translate to "No such file or directory", Rainer?

(Just a gentle 'dig', mate. No harm meant... )

--------------------------------------------------

@cobaka

Ha! I have it! The shell is powerful. Very powerful, but to use it demands precision...

Not JUST the shell, Leslie; that statement applies equally to scripting of any sort in Linux. A single misspelling, a space in the wrong place, a dot (.) where there shouldn't be one, or lack of one where there ought to be.....it completely changes the way the system interprets the command.

Accuracy is key to making things do what you want them to when interacting directly with the system.....which is exactly what you're doing in the terminal. And that IS, of course, what makes it so "powerful".....


Mike.

[taersh]

I don't need to type echo $PATH!
Just $PATH is working.

.....but doesn't "Datei oder Verzeichnis nicht gefunden" translate to "No such file or directory", Rainer?

(Just a gentle 'dig', mate. No harm meant... )

Yes!

That's exactly what I explained in my post above done at 12:16 / 2:16 German Time!

However: the way cobaka described it, it was logically to me to understand it the way, that he's getting that error message only, without the paths being displayed.

[bigpup]

If you have one file scripts.
They are yours and only yours.
As long as they are in a path location, they should run by typing the name in a terminal.

I suggest putting them in /root/my-applications/bin

They are your applications.
All in my-applications.

In Puppy Linux

/root/my-applications/bin/ is in the executable search path,
as set by environment variable PATH.

Therefore, any executable placed in here will be found.

Giving your scripts names that do not conflict with the name of other executables, makes sure that only your script file is found and run. Only your script file has that name.

[wiak]

On the topic of $PATH:
$PATH is a variable not a command.
echo is a command.
This is what I figure: When I type at the CLI (the command-line interpreter/the shell) I must precede the name of a variable by a command.

Refer to following thread for info regarding Linux FileSystem Hierarchy (and similar for systemd systems):

viewtopic.php?p=3085#p3085

[mikeslr]

I second bigpup's suggestion. /my-applications/bin as a location "on-the-path" is unique to Puppies. Consequently, it is less likely to have the hundreds, even thousands, of files other locations "on-the-path" used by 'common' Linux applications will have. [bin and sbin folders don't only house binaries]. Having your unique-to-Puppy scripts in /my-applications/bin makes it easier to find and, if necessary, edit them.

I run masterpdfeditor from an external folder: just downloaded the tar.gz from its publisher, UEXtracted it and moved the resulting folder to /mnt/home (truncating its name). To create a menu entry, all that was necessary was to place an icon in /usr/share/pixmaps, create a /usr/share/masterpdfeditor.desktop specifying where to find the icon and where to find the bash-script 'calling' the executable from its folder on /mnt/home. Created a pet to install the menu-entry into new Puppies. In order to make it my default pdf "reader" I have to type its name in. Did I name it masterpdf, masterpdfeditor, mspdfedit, something else? I made the mistake of locating the bash-script in /usr/local/bin or /usr/bin. Can never remember where. With each new Puppy I waste time trying answer that question. The next time this situation arises I'll try to remember to edit the pet before installing it.

Of course, when not in use, you can place a bash-scripts anywhere, e.g. /mnt/home/my-bash-scripts.

[taersh]

In terminal, which NameOfProg will return its location stored.