The reason why I don't need an apostrophe is because there are no
spaces in the alias.

Spaces are command delimiters. If we don't tell bash that our
command string with spaces is to be treated as a whole, it will treat
it as individual instructions each time it encounters a space and
bomb out.

I want to demonstrate variable expansion.

1) echo '$PATH'

2) echo "$PATH"

3) echo $PATH

You can select the command, the click you mouse wheel into the
console to save typing.

My theory is many FOSS authors actually try and make Linux
friendly to Windows users. Many Linux utilities and programs now
work on 'dirty' Windows file names. Years ago, many Linux apps
would bomb out on bad file names.

Which ones and how many? I don't know. Knowing would be a
discovery process.

What I do is I clean up dirty filenames, so they will work with any
Linux utility or program and make our scripting easier.

Here is what I consider dirty filename for Linux

Elton John - I Don't Wanna Go On With You Like That.mp3

Here is the cleaned filename

Elton_John_-_I_Dont_Wanna_Go_On_With_You_Like_That.mp3

The worst part of the filename was the apostrophe in the word Don't

I think you will find the 'cleaned' file as easy to read as the 'dirty'
one.

If I keep my filenames 'clean'. I don't have to worry about what a
script will do when it processes them.

About six years ago I donated a script, one I didn't write, to Puppy.
It's name is spacereplace. Barry still includes it.
Use it to replace spaces with underscores.

For fine editing, the utility 'ytree' has been the best one I've found,
for ease of use.

Hint: Open it in the directory you want to work in. Hit enter to bring
all the files into a more full window. The rest is intuitive.

Compiling is straight forward

./configure
make install

Don't use the one hosted on Puppy's archive, something is wrong.
Also, it might be an older version.

You are reading and thinking, what more could I want? If everyone did
that, I'd be overjoyed.

jpeps wrote:

Really, you're just substituting one command for another,
"cat" for "<" ("<" is just a redirect command). Both do pretty much the
same thing.

What I wrote was:

In the refined block we have eliminated two external commands,
cat and tr.

The emphasis would have been eliminated two external commands.

You're right about the tr being useless, but obviously when I wrote the
script I thought I needed it.

If we have a choice between an internal command and an external
command - everything equal - we want the internal command. The
reason why is - it is already there. An external command has to be
located and copied to memory to be used.

I think redirection and piping may not even be commands in a
conventional sense. Rather an integral part of the kernel's I/O
(input/output) functions. I could be wrong.

I just did a little searching to determine for sure, but didn't come up with
anything conclusive or inconclusive.

I'll leave it as another unanswered ??? among my myriads of unanswered
questions, until and if I learn the answer.

# it worked, I now have all my bin directories stored in BINDIRS separated
# by spaces, which I will need for the for loop

for i in $BINDIRS
do
find $i -maxdepth 1 -type f | grep $1
done

# I discovered some directories in the path statement don't exist
# /opt/bin/ /usr/local/games/ /usr/lib/java/jre/bin/
# I could modify the path statement but I'll make the mods in the script
# by removing these directories
# I added MODPATH to accomplish this

Linux comes with a utility called "which", but to use it, we need to know
the filename. And it's for locating the path of a known filename.

I call this script whichx, which means to me - which-extended

If I type in this command

whichx cups it will show me the full path and
name of every file containing the text "cups"

Note the use of the escape character \ at the end of the first line of
MODPATH. Bash uses the end of line to signal end of command. If we
wish to keep long lines short we can use \ to tell bash the command
continues to the next line. You cannot have any spaces after the \.

I've tested whichx and included it as a downloadable script.

You will have to adjust or at least test the variable called MODPATH to
make it right for your system.

The authors working on Linux tended not to make too many utilities not
included in Unix.

ls is the Linux equivalent of the MS dir command.

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

With ls or find it is not so easy, yet we can make scripts to add utilities
which don't exist.

I want, for example, to be able to:

* view all non-hidden directories
* nicely formatted
* in dictionary order
* and have an intuitive filename for my script

I can do this, it takes a few minutes to write the script, from then on I
have the script for my Linux systems. This is why I keep my scripts in
their own directories, it is easy for me to retrieve my scripts to new Linux
installs.

My intuitive filename is: ad (that was the switch used in the dir
command and it means to me 'all directories', (only my script doesn't
show the hidden ones, on purpose)

Next I'll explain the commands

find . -type d -maxdepth 1

. is our current directory
-type d means display the type directory - not files
-maxdepth 1 means I don't want to see any subdirectories

'\./\.' is my criteria, using the find command the beginning of hidden
directories, looks like this ./. , if I want grep to look for literal periods, I
have to escape them. Remember our common escape character is the \ ,
the ' ' are used to tell grep the beginning and end of our criteria and don't
allow for any shell expansion

cut -d "/" -f 2

The cut command can be used to remove output, the find command will
output a directory like this; ./foobar , we want it to display only foobar,
the cut command uses / as the delimiter,
like this -d "/" and the -f switch says print only text after field 1

sort -d will sort our text, the -d switch says to do it in dictionary order.
Linux is case sensitive and we want to display like this:

mydocuments
MyFiles

Which would be a non case sensitive sort

grep -v '^\.$' will eliminate a line which only has a period

^ means start of line
$ means end of line
\ escapes the period

We pipe to filter output, the pipe symbol is | , the output from the
command on the left, becomes the input for the command on the right.
When done, the filtered output is displayed on screen.

Now, the parts of the script have been explained, we can put them
together.

Bruce, I am not too clear on why you placed the three echo statements a few posts back. I tried them each and noticed that while the $PATH and "$PATH" were treated as variables, the '$PATH' was treated as a literal. Are what's contained in single quotes always treated as a literal in echo statements?

Oh, and would you be able to make a thread all about regular expressions? That stuff just throws me way off, and I haven't seen too much in the docs about it, but it can probably be very useful to me if I knew better how to use it.

Bruce, I am not too clear on why you placed the
three echo statements a few posts back. I tried them each and
noticed that while the $PATH and "$PATH" were treated as variables,

To show that two would behave the same
One wouldn't

PupGeek wrote:

. . . the '$PATH' was treated as a literal. Are
what's contained in single quotes always treated as a literal in echo
statements?

Maybe always. Maybe sometimes they drive you crazy.

The general rule is single quotes when used in variables inhibit
expansion.

PupGeek wrote:

Oh, and would you be able to make a thread all
about regular expressions? That stuff just throws me way off, and I
haven't seen too much in the docs about it, but it can probably be
very useful to me if I knew better how to use it.

It could throw anyone way off, if not presented on a very easy
gradient from start to finish.

Puppy's help system contains a page on regular expressions.

I think a page could be started in the programming section of the
forum for people wishing to learn and ask questions.

OK, really, probably a noob question, but if I write scripts using alias`s on my system, they will not run on other systems???_________________Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...

OK, really, probably a noob question, but if I write scripts using
alias`s on my system, they will not run on other systems???

Since the days of Moses, Puppy started using BusyBox extensions for
its common command utilities.

I like using genuine utilities.

This can cause some differences which need adjusting when porting.

I recently setup 5.20 and ported my mountcontrol script to Puppy. It
wouldn't mount an NTFS partition. An on screen failure about not
understanding a -f or something.

My script was written for the true mount command. Puppy's mount
command is a script written by Barry.

The real mount command in Puppy is called mount-FULL

I did a search and replace. Replaced all instances of mount with
mount-FULL

~~~~~~~~~~~~~~

When we make our scripts, we want them portable. I already knew
about Puppy's mount-FULL, because of this I could have made the
'control center' automatically portable with a couple simple
commands at the top of the script by using a variable for the
command 'mount'. Very simple, as shown below.

Code:

mntcmd=mount
[ -f /bin/mount-FULL ] && mntcmd=mount-FULL

The 'control center' would have adjusted itself with no user
intervention.

Where I often have problems when porting scripts is directories
don't exist on the new setup which existed on the old one.

This is why we want to keep in mind conditional checks and
branches when writing scripts.

Here is an example:

Code:

[ ! -d $destdir ] && echo "$destdir doesn't exist, exiting" && exit

Note here how a potentially damaging script becomes safe.
I check the condition, branch to a message, branch to quit.

Ideally you would use so much care, you could hand your script to
another Puppy user and have it work.

If you wish to share scripts, you must think of a lot of things, far
beyond your individual setup. Also, that a script might be floating
around for years.

Here is an example of conditional checks and branching. We want to
make sure the user is advised, if he is not using 5.20

Code:

grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are \"not\" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi

Please note how we indent and nest our statements and commands.
It makes reading much easier.

On second thought, I'll explain. If you are working in a group, your
friends won't like it if you don't indent. And in a group do things by
convention, such as variables in UPPERCASE.

if begins our if statement, fi ends it.

By indenting everything inside it, we can easily see where the if
statement begins and ends. Simply look straight down the column
for the end of the statement.

I put an if statement inside an if statement and indented again.

Look at the difference in readability with and without indenting.

Code:

grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are \"not\" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi

Code:

grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are \"not\" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi

This example is a verysmallsnippet. You can run into statements
that begin and end a hundred lines later. More lines than can be
viewed in the editor at one time.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum