Basic Shell (Console) operation for beginners

[jpeps]

An Intrusion Prevention Script

Might as well store colors in a separate file:

save "colors" in $PATH

Code: Select all

#!/bin/sh
 
### example: echo -e $RED"Hello" 

## Black background

 export RED='\E[31;40m'
 export WHITE='\E[37;40m'
 export GREEN='\E[32;40m'
 export YELLOW='\E[33;40m'
 export MAGENTA='\E[35;40m'
 export CYAN='\E[36;40m'
 export BLACK='\E[30;40m'

## White background

# export RED='\E[31;47m'
# export WHITE='\E[37;47m'
# export GREEN='\E[32;47m'
# export YELLOW='\E[33;47m'
# export MAGENTA='\E[35;47m'
# export CYAN='\E[36;47m'
# export BLACK='\E[30;47m'

Then:

Code: Select all

#!/bin/bash

. colors

KEYWORD=foobar
SAFEFILE=/var/log/safe~
trap caught 1 2 3 4 5 6

function caught() {
   echo date >>$SAFEFILE # remove this echo
   echo -e $RED"-- System has been compromised, shutting down now --"
   echo -e $WHITE"poweroff" # remove this echo

}

if [ -f $SAFEFILE ] ; then
   echo date >>$SAFEFILE # remove this echo
   echo -e $RED"-- System has been compromised, shutting down now --"
   echo -e $WHITE"poweroff" # remove this echo
fi

echo -n "Login: "
read a
if [ x$a != x$KEYWORD ] ; then
   echo date >>$SAFEFILE # remove this echo
   echo -e $RED"-- Unauthorized Access Attempt --"
   echo -e $WHITE"poweroff" # remove this echo
fi   

[jpeps]

[ "x$cnt" != x20 ] works just as well. the thing is that with 'sh' (only single-brackets supported), the first value cannot be null. the other way to avoid that is to reverse the values -but it reads really weird:
[ 20 != "$cnt" ]

If you are writing for bash, use double brackets and then the first value can be null and no errors result:
[[ "$cnt" != 20 ]]

Only a problem for variables without quotes:

Code: Select all

#!/bin/bash

echo "with quotes:"
[ "$VAR" != "2" ] && echo "no error"

echo -e "\nwithout quotes:" 

[ $VAR != "2" ] && echo "no error"

[PupGeek]

Might as well store colors in a separate file:

save "colors" in $PATH

cool idea jpeps, but aren't we really defining each color in the environment and not saving them to the $PATH variable?

[jpeps]

Might as well store colors in a separate file:

save "colors" in $PATH

cool idea jpeps, but aren't we really defining each color in the environment and not saving them to the $PATH variable?

What I meant was to save the script as "colors" and put it somewhere in your PATH so that you can reference it. (e.g, /usr/local/bin:/root/my-applications/bin...)

[PupGeek]

can we place a command to run the colors script in the bashrc file?

[jpeps]

can we place a command to run the colors script in the bashrc file?

Good thinking...yes. Just add ". colors"

[PupGeek]

I know it seems a bit redundant on the surface, but it provides color formatting while keeping the bashrc file nice and neat by defining the variables externally.

[Moose On The Loose]

Another useful trick for making the help message is the here-document

Code: Select all

# (cat - | more) <<aaa
> hi there
> how are you
> aaa
hi there
how are you
# 

The "aaa" in the example could be any string

[jpeps]

I know it seems a bit redundant on the surface, but it provides color formatting while keeping the bashrc file nice and neat by defining the variables externally.

Actually it's not redundant. As long as you're using the bash shell, you don't need to add ". colors" to scripts, and can use colors right on the terminal.

Code: Select all

[ -f  /tmp/log ] ||  echo -e $RED"error"

[Bruce B]

Planning Your Program

Carefully plan what you want your program to do. The coding is partially
complete while planning, because a portion of your mind is already
working out how to do it. You will be more relaxed when coding. You will
know when you are done. You will know if you left something out.

You can give your plans to any coder and have someone else do the
coding and get the same end result.

When done, you can add your plan as comments. Anyone in the future
will understand the program's purpose and specifications.

Wanted an alarm clock

My situation

I sleep listening to music. If a quiet alarm goes off, I may not hear it. If
an alarm goes off, which is easy to turn off, I might turn it off and fall
back asleep.

Specs

» usage example: alarm 8 (for eight hours)
» is shell script that runs in background
» plays a sound file even if xmms or mp3blaster is in use
» (I can adjust the gain in the sound file to make it loud)
» play either mp3 or wav alarm file
» cli player: wavplay or mpg123 or?
» continuous playback until turned off
» name of player set by variable
» name of sound file set by variable
» hard to turn off, maybe type in the name of a script to turn it off
» (making it hard, forces me into an awake state to turn it off)
» uses very little CPU while running
» only needs to be accurate to within a minute or two


~

[Bruce B]

Code: Select all

 export RED='\E[31;40m'
 export WHITE='\E[37;40m'
 export GREEN='\E[32;40m'
 export YELLOW='\E[33;40m'
 export MAGENTA='\E[35;40m'
 export CYAN='\E[36;40m'
 export BLACK='\E[30;40m'

A sourced file must be in your current directory if used like this.

. colors

More safe would be a specific path . /root/bin/colors

What I wanted to explain is it would work without exporting, example:

Code: Select all

 RED='\E[31;40m'
 WHITE='\E[37;40m'
 GREEN='\E[32;40m'
 YELLOW='\E[33;40m'
 MAGENTA='\E[35;40m'
 CYAN='\E[36;40m'
 BLACK='\E[30;40m'

/etc/profile configures many aspects of your system

/etc/profile.local is a file which probably doesn't exist, but if you make it,
then it is an extension of /etc/profile

To see why and how this is, the answer is inside /etc/profile

Exporting the specific variables at this low level, should cause the
variables to exist in all shells. This may be something you want.

Exporting has befuddled programmers before, wondering why the export
didn't carry over.

A simple answer and solution is: Do the exporting in /etc/profile or in this
case /etc/profile.local

So, you might try putting your exported color commands inside
/etc/profile.local, reboot and see if in fact they always exist for your use,
as you want them.

~

[Bruce B]

/etc/profile.local

Here is the answer from line 201 of /etc/profile
Puppy version 5.20
But it was added at Puppy version 1.0.5

Code: Select all

#v1.0.5
#personal customisation file...
[ -r /etc/profile.local ] && . /etc/profile.local

The -r switch means readable file. Remembering that a sourced
file is not a shell script, doesn't need to be executable.

If we start a sub-shell to export, we likely lose the exports when it closes.
It must be sourced at a low level. /etc/profile is low enough.

~

[r1tz]

Bruce B,

You rock!

ritz

Hey, we need a Content page!

EDIT:

I liked the dir command. If I wanted to see all the directories and only
directories, I could type 'dir /ad'

Why not

Code: Select all

ls -d */

[jpeps]

A sourced file must be in your current directory if used like this.

. colors

More safe would be a specific path . /root/bin/colors

If your scripts are in $PATH (like they should be), you can access them without having to include the path

/etc/profile configures many aspects of your system

/etc/profile.local is a file which probably doesn't exist, but if you make it,
then it is an extension of /etc/profile

I noticed that .bashrc in /root will override /etc/profile.local.

What I wanted to explain is it would work without exporting, example:

What sometimes works doesn't mean that it's good coding. Check out the /etc/profile script, for example.

[Bruce B]

A sourced file must be in your current directory if used like this.

. colors

More safe would be a specific path . /root/bin/colors

If your scripts are in $PATH (like they should be), you can access them without having to include the path

Sourcing doesn't do a path search.

[Bruce B]

What sometimes works doesn't mean that it's good coding. Check out the /etc/profile script, for example.

We set our own bars, let's make them high.

[jpeps]

A sourced file must be in your current directory if used like this.

. colors

More safe would be a specific path . /root/bin/colors

If your scripts are in $PATH (like they should be), you can access them without having to include the path

Sourcing doesn't do a path search.

Try it, it does.

Code: Select all

~ $ . colors ; echo -e $RED"hello" 
hello
~ $ which colors
/root/my-applications/bin/colors
~ $ pwd
/mnt/sda2/Desktop
~ $              

If your reference file is, say, /etc/profile, then you'd need to include the path, like in .bashrc

edit: BTW/ "$!/bin/sh" at the top of the "colors" script is unnecessary.

[technosaurus]

In working on bashbox I have developed several scripts into functions.
This allows you to add them to your .bashrc file and use them as a script. (I don't use the .bashrc in bashbox b/c I am aiming for ash/hush compatibility, but achieves the same effect)

for instance:

copy the contents of /root/my-applications/bin/colors to

colors() {
# insert contents of script here - without the top line (#!/bin/sh etc...)
}

and paste it into your .bashrc file

now use colors as if it were a script

it is a lot faster to call a function than to run a script (~20x) ... some scripts may require minor modification - particularly if they use $0 or rely on its relative directory location or similar

I have converted all puppy scripts to functions (over 1MB worth) and it still takes significantly less time to read them all as functions than to just load a single separate script

[Bruce B]

If your reference file is, say, /etc/profile, then you'd need to
include the path, like in .bashrc

True, because /etc/profile is sourced by a file in /etc/rd.d, and
/etc/profile automatically sources /etc/profile.local

edit: BTW/ "$!/bin/sh" at the top of the "colors" script is
unnecessary.

True and you must source it at a low level if you want exports. Best if
you want exports put it in /etc/profile.local

Is this starting to make better sense?

[Bruce B]

Why not

Code: Select all

ls -d */

That's an easy answer, because I didn't think of it. One thought leading to another.

Script name: ld or ad or something else

Code: Select all

#!/bin/bash
ls -d */

~