Ask your nix questions here instead?

[liudr]

I am a beginner with the your nix system or linux system in general. Sometimes spelling out one line of shell command can get me stuck when experts say you can easily do this and that without mentioning the exact commands. So today I was checking how to autorun a program, much like DOS autoexec.bat. You turn on the computer and expect your program to run without you having to log on or manually start it. I wanted this in linux. So I asked and googled. Found a thread on unix.com The OP was apparently noob and actually wanted some hands holding regarding how to transfer hand-typed commands into a script, like how to do xyz [enter] in command line in a script. And it was met with stone-cold responses. Some expert even when to the half page length to scold the noob OP that he should learn the basics of scripting on book page 1 but refused to give answers in say two line descriptions that their grandparents could understand.

As a nix noob myself, I am guessing you just include the command name in the script like xyz or if it is executable do ./xyz or maybe /home/me/./xyz, is that even right? I can try it though. This is the very reason that unix and linux turned me off for decades. Too hard to use and experts act as snobs (or a better word for it). So I am thinking I might be better off asking your nix questions here instead of on "expert"-filled forums everywhere else. 

[Chagrin]

A dot "." means the directory you are in now. ".." is one directory level down. So when you type "./foo" it means you want to execute the "foo" command in the directory you are in. If you do not prefix the "./" to the command then your shell will only look for the command within the set of directories in the environment variable $PATH. And, FWIW, a tilde "~" refers to your home directory, so instead of "/home/me/foo" you could type "~/foo".

Typing "/home/me/./foo" is the same as "/home/me/foo". It's like saying you're changing to "home", then "me", then the same directory, then executing "foo". You can do lots of weird things like that, like "/home/./me/../me/foo", etc.

Sometimes the $PATH environment variable will already include the "." directory (then instead you can just type "foo" instead of "./foo"), but it's a practice generally frowned upon as it can lead to accidental execution of non-programs. It's a debatable rule, for sure, but don't expect to find "." included in $PATH for any popular Linux distribution.

If you're writing scripts it's typically best to use the absolute path, e.g. /home/liudr/foo. It's easy to goof up your scripts' current working directory and use a path incorrectly.

All of these behaviors are identical in Windows as well AFAIK. It's actually not a Linux thing

[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

[el_supremo]

".." is one directory level down

I would call it "up" not down.

If you are in directory /home/whatever/mydir and you refer to ../some_file then you are referring to /home/whatever/some_file

Pete

[GoForSmoke]

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!

[Chagrin]

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.

".." 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?

[Nick Gammon]

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:

Code: [Select]

man 5 crontab


[el_supremo]

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

Pete

[Nick Gammon]

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

[funlw65]

http://jonathonhill.net/2009-04-23/auto-start-a-shell-script-on-ubuntu-server/

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/

[liudr]

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?

[Nick Gammon]

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):

Code: [Select]


./foo


Run in the background:

Code: [Select]


./foo &


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

[Chagrin]

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.

Run in the background:

Code: [Select]


./foo &


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: http://www.enderunix.org/docs/eng/daemon.php

[liudr]

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.

[Nick Gammon]

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.