Getting SNMP to access the BMP180 pressure sensor.... running a script as root?

But what point is there in sending the output to a file? I don't understand.

There is no point in sending it to a file when your next step will be to read it back from the file.

There is, if unless you do, there is no output to read....

Indeed. When the Fedora distro installs or upgrades packages that run in specific users, or groups, its package management software, yum, is responsible for ensuring that the required users or groups are set up: it is not the responsibility of the packaged program(s) to do that.

It would seem likely that the Debian/Raspbian package manager has the same responsibility. I'm putting it that way because I've seen yum adding users and groups when a package upgrade requires it but I haven't (yet) noticed apt doing the same for Raspbian.

Whenever you run a program, e.g. you run:

echo 'Hello world'

the 'echo' program opens three files: stdin, which is connected to your keyboard, stdout and stderr, which are both connected to your screen. echo is a small utility that writes any arguments on its command line to stdout, so you will see "Hello world" appear on your screen. stdout is a program's default output file and stderr is a second output file that, by convention, is where a program should send error messages and debugging information. Since a daemon (or server if you prefer) isn't started from a terminal, its stdin, stdout and stderr files can't be connected to a terminal. So, to keep things tidy, by default it connects them all to a device called /dev/null. This, by design, acts like an empty file if it is read and throws away anything written to it.

So, if you want to read stuff output by a script run by a daemon you have to explicitly send it to a file which you can read later. You can send the output to any file, but since /tmp is a place that is accessible to any program or daemon running under any user, it is a convenient place for this script to send anything you'll want to look at after it has been run.

Ok, now I get it. You don't know the capabilities of the shell. That can happen.

But I tell you it is no problem to catch the output of a command inside a shell script without putting it in a file.

You don't need to teach me how it works, especially when you are wrong.

The is NO NEED to put the output in a file. Period.

It does.

Of course, and redirecting it to a file which persists after the daemon invoked script exits is one way of doing it.

Let's face it, what other mechanism exists that persists beyond the life of the shell?

Perhaps we are not behind your thinking, just way ahead of it?

There is no need to read the output after the script exits, either.

Except in this case for debugging, it was suggested as a good way to work out why it was failing.

Stop digging.

the instructions given were so you could identify which user your daemon process was actually running with, if you can see the output from a daemon without writing it to a fill then simply do so.

as you know how everything works than we can assume you dont actually need any further assistance.

good luck with your problem because I doubt that you will be getting any more help now.

It is not my problem.

Of course, when you want to know how your process is running for debugging purposes you would not use "whoami" but instead would use "id".

When you want to use the output of a command in a script there is no need to write it in a file. whoami could be useful because it provides a simple output. "id -un" does the same thing.

No you have a much bigger problem. ;-)