Raspberry Pi and /dev/mem access

Try running "sudo su", then you will be in a shell that has all root privileges.  When you run your Python script and it will definitely have all rights to access /dev/mem.

Hello All,

Thank you for your input.  The program works!  My problems were related to permissions, paths and misunderstands on my part.  I still have many questions that probably will be answered with experience.  I am using "Raspberry Pi for Dummies" and "Programming the Raspberry Pi" as references, but they are very limited when trying to answer questions pertaining to Raspberry Pi, GPIO, Linux, Python and how they all work together.  Is there another reference that I could be using or is "trial and error" and Google the best references?

Again thank you.  Next step is PWM.

Regards,

Bill

That's definitely one way around it

Yes, same here. Guess these args have changed over time.

I just tried reading man man, and think I've found something ok-ish:

man -k [a-z] | more

That lists over 3000 entries, single-line.

Could be good for a general overview.

Or, of course, to search for anything hex related as an example:

man -k hex | more

yeah, man -k, apropos

Also in the same vein the command line switch "--help" as a good punt when there's no "man" page

Showing how often I actually use it.. it took ages to remember the other command  'info' but since it's sometimes populated you can add it in to complete the ensemble  of self help

Can I also shamelessly plug Steve Parker's Blog site and book  it's an excellent resource to programming Unix command lines in general and bash in particular. I also must say I had a good time working with him .....yes his scripting is pretty good

I looked at Parker's site and it seems that he is missing one or more of the most powerful constructs in shell scripts.  It involves external commands.  For example,

#!/bin/sh

for a in `ls /var/log`

do

echo $a

done

then there is the

NOW=`date`

and it's bretheren.  For example:

#!/bin/sh

FOO=3

RES=`expr $FOO + 1`

echo $RES

There is one other item that is almost always missed when dealing with shell scripts.  This is one item that is really difficult to resolve unless it is explained.

In the following shell script, each line is supposed to be echoed to STDOUT.

#!/bin/sh

for a in `ls -l /var/log'`
do
echo $a
done

here is partial output.

total

724

-rw-r--r--

1

root

root

0

Feb

1

06:25

Clearly this is not what is needed.

What happens is that the preset variable IFS is getting in the way.  IFS is defined by default to  tab. space, and newline.  That means that if a space or tab or newline is encountered, the shell assumes the end of a record.  To fix the program needs the following to be set

#!/bin/sh

IFS="

"
for a in `ls -l /var/log`
do
echo $a
done

Once that is done the output looks like this:

total 724

-rw-r--r-- 1 root        root      0 Feb  1 06:25 alternatives.log

-rw-r--r-- 1 root        root   1037 Jan 31 07:07 alternatives.log.1

-rw-r--r-- 1 root        root    162 Jan 17 10:34 alternatives.log.2.gz

-rw-r--r-- 1 root        root    669 Sep 29  2013 alternatives.log.3.gz

-rw-r--r-- 1 root        root    174 Aug 11  2013 alternatives.log.4.gz

-rw-r--r-- 1 root        root   3476 May 23  2013 alternatives.log.5.gz

drwxr-xr-x 2 root        root   4096 Mar  1 06:25 apt

-rw-r--r-- 1 root        root      0 Jan 29 06:25 aptitude

-rw-r--r-- 1 root        root   1599 Jan 28 21:50 aptitude.1.gz

One of the handier things is the forever loop.:

#!/bin/sh

while true

do

ps -ef | grep cron|grep -v grep

done

Armed with this info, the lowly shell script is raised to new levels of usefulness.

For several reasons the Advanced Bash-Scripting Guide is by far the best reference available. The first reason is that it is available for free in HTML and PDF at http://www.tldp.org/guides.html. The second is that it is crammed

full of useful examples. The third is that it is actively being maintained. The last revision (10) was March of this year so it tracks most of the latest bash changes/additions. About the only downside is that it is 916 pages long

(LOTS of examples). You don't have to read the whole thing, although you probably should at least skim through all the chapters to see what it can do.

It's also worth to note the almighty pair find and xargs for this kind of sequential process.

As example the script:

#!/bin/sh

IFS="

"
for a in `ls -l /var/log`
do
echo $a
done

Is equivalent to:

find /var/log -maxdepth 1 -print0 -type f | xargs -0 ls -ld

In this case find searches for all the files in /var/log but terminates them with a null character to avoid problems with the IFS. xargs gets the output of find and per each field - taking into account it's terminated with null and not with a space - executes the command ls -ld.

It's a pair of commands I use almost daily.

In all the years that I have been administering Unix systems, I can remember only one time where I actually tried xargs.  In short, I have no use for xargs at all.

find /var/log  -type f -exec ls -ld {} \;

or better yet.

find /var/log/ -type f -ls

On multi-user office systems where there are impossible filenames like "foo*bar.***"  and worse exist, getting the inode number of a file comes in handy

cd /home/noobie

ls -lai | | cat -v | more

the cat -v turns escape char sequences like <clear screen> into something visible.

when you see the offending filename the inode number will be first field

Then it is a simple matter of

find . -inum 12345 -exec mv {} newfilename \;

I wonder what would break if I removed xargs from my systems.

as a matter of fact, ls isn't really needed either.  When performing emergency surgery on a system, "echo *" or "echo .* *" is a reasonable substitute.

In all the years that I have been administering Unix systems, I can remember only one time where I actually tried xargs.  In short, I have no use for xargs at all.

find /var/log  -type f -exec ls -ld {} \;

or better yet.

find /var/log/ -type f -ls

On multi-user office systems where there are impossible filenames like "foo*bar.***"  and worse exist, getting the inode number of a file comes in handy

cd /home/noobie

ls -lai | | cat -v | more

the cat -v turns escape char sequences like <clear screen> into something visible.

when you see the offending filename the inode number will be first field

Then it is a simple matter of

find . -inum 12345 -exec mv {} newfilename \;

I wonder what would break if I removed xargs from my systems.

as a matter of fact, ls isn't really needed either.  When performing emergency surgery on a system, "echo *" or "echo .* *" is a reasonable substitute.

Your  ' -exec ls {} \' ' will execute ls for each file. If you want to do something very small for lots of files executing the new process ends up taking lots of time. So xargs to the rescue to bunch up a  number of arguments and execute the program many times less often. Nowadays we have '-exec ls {} +' .

On the other hand, I have a raid array that has ten disks. When I do "find -ls", the find process will run until it needs something from disk wait for the result and then go on to need something new from the disk. In all either a single disk is doing something or the CPU is doing something. very little overhead. And just one of my ten disks is running. With xargs, I can tell it to run X processes in parallel, each having N arguments. The result is that I can get more of my disks to "DO" something (i.e. now almost all ten disks are acctive at the same time as opposed to max 1 in the simple case). The result is that I get almost a 10fold performance improvement of the overall process.

Anyway, that's an example of where I used xargs that couldn't be solved with find alone.

As with most thing  *nix, there is no one right way to do something.  I have gone almost 30 years without xargs.  I think I will do without it some more.

I've gone almost 20 years before discovering the wonders-of-xargs....

I still don't have any use for it..