Ask your nix questions here instead?

It has been so long since I did much command line that I won't try details...

but two of the "power tools" you could use are redirection and pipes. Look those up.

With one command line you can initiate keyboard entry into sort into an output file. That's okay but keep it short or there will be typing errors that force the data entry to be repeated, erasing any savings you thought to gain... Murphy was right!

liudr:
So I thought I HAVE TO type ./ before an executable. I have a test program I compiled from C. It runs if I do ./hello but will report "no such command" error if I do hello

The rule is that if the command you enter does not contain any slashes (and the command is not a builtin function of the shell) that your shell will search the list of directories in the $PATH environment variable ("echo $PATH" to see the current setting) to find the executable. If $PATH does not contain "." then it won't find it. That is why you have to type "./hello".

The full details are described in the bash man page: type "man bash", search for the string "COMMAND EXECUTION" by typing "/COMMAND EXECUTION" and keep pressing "n" to repeat that search until you get to the section describing it. "h" for help, "q" to quit.

el_supremo:

".." is one directory level down

I would call it "up" not down.

Yeah I think I always say that backwards. But if it's a directory "tree" then why is the root directory at the top? :slight_smile:

Windows will check the current directory for an executable, Unix doesn't. Hence you have to put ./ in front of anything in your current directory you want to run (this includes programs and shell scripts). Unless the "current directory" is already in the path of places it checks.

As for autoexec, there are ways of doing that through the GUI interface. One way also is to use cron (chronometer) which lets you run things periodically. One option with cron is to run a program/script at reboot time. Try:

man 5 crontab

But if it's a directory "tree" then why is the root directory at the top?

A good question.
Whenever I've seen a representation of a hierarchical directory structure drawn (or when I've drawn it myself), the root is always at the top. So ".." is up.
But a tree's root system can "branch" just as much below ground as the branches above ground do. Perhaps the "root" directory ought to be called the "trunk" directory and then you could take your pick whether ".." goes up or down :slight_smile:

Pete

Don't family trees start with the "head" of the family at the top?

The problem is the startup system can differ from a linux distro to another. And this method may be old already... I'm not in sync with Ubuntu...

And the opposite:
http://www.tainguyen.com/2011/06/12/disable-ubuntu-services-autostart/

Many great answers! Thank you all! I decided to follow a daemon program tutorial. It fits the bill better than running a program periodically. The program I am going to run needs to stay "resident" or in the background and periodically snap pictures on two cameras. If the user decides to change these periods, I want them to be able to do this with the least effort or understanding of nix. I am thinking of this way:

Write a daemon program. research how to add this program to autostart at boot up and hope to start after the USB TTL adapter drivers are started so the serial cameras can be accessed.
Daemon program monitors a file called config.txt. It will contain the periods of each camera and a few other parameters. When the file is changed it will grab the update and operate according to the new parameters.
Ask user to log on to raspberry pi and type config (allias for nano config.txt), modify parameters and save with ^O exit with ^X.
Alternatively ask user to log in and type cam01period 10 (alias for a script or c program that updates the period to 10 minutes).
Alternatively ask user to point browser to raspberry pi ip address (port forwarding) and use a web based graphical interface, which does the same thing (modify the config.txt).

Suggestions? Comments?

Write a daemon program.

A daemon is basically an ordinary program, running in the background. eg. for a given program foo:

Run in the foreground (ie. your terminal window):

./foo

Run in the background:

./foo &

Normally you redirect output (if any) to a file in this case.

http://wiki.debian.org/BootProcess

Your software package should include an init script that would be placed in /etc/init.d (look at other examples in that directory) and also create symlinks from /etc/rc*.d directories. There are plenty of pre-existing examples that you can poke around at to help understand everything. For example try "ls -l /etc/rc*.d/anacron" to see how the Anacron daemon is configured within the various /etc/rcX.d directories.

That would die the moment the user logged out. You need to use setsid() to divorce yourself from the shell process.

Here's a good tutorial on creating a daemon: Unix Daemon Server Programming

Great! Thanks. I tried that myself. The background process did die when I log out so no go. So you are saying that sid is session id, I see.

If I put ./foo & in the init.d does it run when someone logs on or when system boot? I'm reading your suggested reference so hope to get an answer there as well.

Chagrin:
That would die the moment the user logged out. You need to use setsid() to divorce yourself from the shell process.

I was simplifying a bit. I had been using nohup, but it sounds like setsid could be an alternative.

If I put ./foo & in the init.d does it run when someone logs on or when system boot?

The init.d stuff is for system booting. There is a script that runs on startup, that runs all the scripts in the init.d directory. Again that is simplifying a bit.

Sorry -- I'm just trying to be terse, not rude. I'm not sure how far we can overwhelm Liudr before he smashes the Pi with a hammer ;). Judging from earlier posts I get the feeling that Liudr would rather have everything performed in the executable rather than using nohup or other scripty methods (cron, xinetd, etc.).

A little Perl can go a long way....

Chagrin:
Sorry -- I'm just trying to be terse, not rude. I'm not sure how far we can overwhelm Liudr before he smashes the Pi with a hammer ;). Judging from earlier posts I get the feeling that Liudr would rather have everything performed in the executable rather than using nohup or other scripty methods (cron, xinetd, etc.).

Keeping my cool here (at least until I get a good box for the pi to smash against the wall with minimal damage). At the start of the day I knew nothing about background processes end at logout, daemons /etc/init.d/ etc. and now I have my basic understanding. I have several books but they are thick and don't talk to me. I am very appreciative with what you all provided here. I have just installed a simple script with update-rc.d that just runs the daemon I wrote (it deletes delete.txt in my home director every 5 seconds). I'm in a good position to read more books and online references. I think cron is possibly next. Also need to know how to tweak make files created by eclipse IDE. It's too massive to run on raspberry pi but did create a makefile. After some more reading I might be able to compile my projects with this makefile in console to save time. Then maybe look for solutions to cross compiling so I can develop the project on a Debian laptop, and occasionally cross compile for raspberry pi to test it out. Many things to learn.

liudr:
I have several books but they are thick and don't talk to me.


It even doubles as a personal defense weapon if anyone sneaks up on me while i'm working.

You might have better luck starting out with a version of Ubuntu. Its a lot easier to find new user help threads for Ubuntu, and most of the settings will transfer over to Debian.

Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Or even better, create a new user that only has permission to do what you need it to do. Like the Apache user is for the Apache webserver.

wizdum:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Or even better, create a new user that only has permission to do what you need it to do. Like the Apache user is for the Apache webserver.

Sounds like the best and safest way to do things if I knew how to deal with user account already :wink: I am behind on my linux cookbook, which is a book on how to use linux. This motivates me. So is there a programmatic way to create such a user name? I wanted to spend the least time to set up and tweak each unit after my program is ready. If I can run a script or c program to create this account, it will be even more attractive option.

If I just installed the script that calls my daemon with sudo update-rc.d, the daemon will run as root, at system boot, correct? There's no need for anyone to log on for daemons to start, right?

I feel like different linux flavors are equally difficult to me since there is a command for everything and most of which I don't know. Programming on linux is probably not related to ease of use of GUI. I have a pidora image that I have not touched yet. Since raspberry pi recommends the raspbian distribution, I followed along with installing debian on my older laptop. Installation was not bad neither was GUI under KDE. It's relatively responsive on a 2.4GB core 2 duo and seems to run fine with 3GB ram. My main laptop with 4GB ram always fills up easily when windows vista loads up and I felt like it needs 6GB to do "blink" :wink:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Not sure what account starts the daemon :blush:

I did sudo update-rc.d script_name

root I guess?

liudr:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Not sure what account starts the daemon :blush:

I did sudo update-rc.d script_name

root I guess?

Don't quote me on it, but i'm pretty sure sudo just gives your current account certain elevated permissions (that are specified in the sudo configuration). I think you can do something like sudo update-rc.d script_name.sh -u USER.