1. Oh woops I read number 2 wrong :/

Uh..I have no idea how to start to explain...

Basically, it makes my graphics cards hash using Open CL using this:

https://github.com/m0mchil/poclbm

2. Okay well I guess bootup means right when the computer starts so I'll just say upon login then. (When Ubuntu is actually running and stuff right?)

erm / is the root DIRECTORY, the file system being a tree and / being the root of that tree
root account is uid 0
the linux kernel treats uid specially and grants all permissions to that uid
/etc mostly is mostly for configuration files and startup scripts
the files in /etc are owned by user root and therefore only user root can edit them
but lack of care when editing the contents of /etc can leave you with a machine in need of a format.
p.s. many modern distributions have security policies that prohibit root from directly logging on into the gui.

1 members found this post helpful.

Yes, I'll correct my post w.r.t. dir.

You have got to be absolutely out of your mind. No time? Also no time for a simple web search? You have people tossing the solution at you and your response is "can someone do it for me?"

Here a post from 2005,
http://embraceubuntu.com/2005/09/07/...run-at-bootup/ Or maybe you can't be bothered to get off your ass and check the UBUNTU help pages https://help.ubuntu.com/community/UbuntuBootupHowto where it specifically tells you how to do what it is you want to do (just like the debian link I gave you), to quote, because you don't have time to read plain english:

Sorry man. I'm just really frustrated because I've been trying to solve this for the past 3 days. I know nothing about Linux

Okay, something I've just thought of why it isn't working:

My actual "script" i want to run is in a folder in my home folder. Normally I would run this script by opening up a terminal and saying:

cd <script folder>
./script --user=user --pass=pass --host=host --port=8332 --device=0 and etc.

Because I don't want to type that 4 times every time I bootup, I've put those two lines into a txt file in my home folder. I make it executable and instead of typing all of that in terminal, I just type

./script1

Maybe this isn't working because I've put MY script into the startup. So it's not actually opening it correctly. What it's trying to do is open up that txt file that opens up another script. So, knowing this, (I think) I need something like this for it to work:

*Open up a terminal upon login.
*Tells that terminal to open up my script in the home folder, to open up the real script.

OR

*Tell the terminal to say:
cd <script folder>
./script --user=user --pass=pass --host=host --port=8332 --device=0 and etc.

Is there a way to do this guys? I appreciate your time trying to put up with my stupidity

I just did this, but nothing happens when I reboot.

According to your post #16, you want it at login, but in post #20, you mention boot-up. Which is it(!)

For login you add the cmds to the (hidden) file for bootup, add to
if Ubuntu has that; look at the Ubuntu forms/home website. \

Note that at bootup, this will be being called by the root-owned startup process, so you'll need to specify the complete/absolute path to all cmds/files needed/referenced.

Well you told me that there was a big difference but never said what the actual difference is... :/

No.

init, and the shell scripts it runs, are run before the login prompt is even displayed. If you system has a splash screen, then that's when they run.

Anyway, you should seriously learn at least the very basics.

http://linuxcommand.org/

http://rute.2038bug.com/

The difference is what it is ...

You can either

1. have it run ONLY as the system is booted up (regardless of whether ANYONE logs in)

OR

2. have it run ONLY when a specified user logs in (ie it won't run at boot up)


(you could have both, but I can't imagine why you would ... )

In the end I just ditched the whole thing. I needed X for my script, so Startup Apps and init.d won't work. I disabled X and tried to use a .xinitrc file to start up my script, but then I couldn't figure out how to use crontab to startup X correctly.

My solution: Run the program on the computer already, and then hibernate. Use WoL when I need the program to start. Works pretty well

For starters:

1. Boot
   Boot happens when the computer starts up or reboots. It loads all the necessary drivers and starts the necessary services. If you want a task to always run, and do not care whether anybody is using the machine or not, create a service script in /etc/init.d/ for it.
2. Login
   1. Graphical login
      It does not matter whether you need to type your username and password or not. After each boot, reboot, and logout, whenever you get back to your own desktop, you have logged in: login has occurred.
      The time from a login to logout (or shutdown or reboot) is usually called your session. For a graphical login, it is specifically an X session.
      Depending on which desktop environment (KDE, Gnome, XFCE for example) and window manager you use, there is a file or directory in one of the .something directories in your home directory that specifies which applications are started for you automatically when the session starts.
      Many desktop environments ask to, or save automatically, your running applications into that file/directory at logout, so that they reappear automatically at the beginning of your next X session. For example, Firefox will automatically open to the page or tabs you had open when logging out and saving the session. Most X applications are session aware, and will work this way.
   2. Text login (SSH login, text console, single-user text mode)
      Depending on how you logged in, this is often called an SSH session or login session. This is closely related to a Terminal session mentioned next.
      It is possible, but not too easy, to differentiate between text login, terminal session, and a simple shell prompt: they all tend to use the same configuration.
3. Terminal session
   A terminal session is basically just a shell prompt, except that the entire window or screen can be manipulated, for example via the curses library. (That gives you quite nice text-based windows, but still no graphics. You can do all kinds of stuff with ANSI escape codes, without a terminal session, but you cannot check if the user's end supports any of it, or how; you can only do it blindly, and hope for the best.)
   You can start a terminal session by starting a terminal application in an X session, or by connecting via SSH (SSH session) and so on.
   (If you use the -t option to SSH, you get a terminal session, but if you don't, you get a simple shell prompt. In most cases the difference is irrelevant; it's just that some programs do require a terminal to work properly. Apparently, Bash does some basic sniffing that gives you some terminal properties even when not using a terminal session, using the TERM environment variable.)
   Most terminal applications can also be told to just run a specific script. Most can also be started minimized, so the window will stay hidden until you want to interact with the script, or just look at its progress.
4. Shell prompt
   This is where you can input commands.
   Whenever you start a new shell prompt (no matter how), shell startup files are run. Most shells have a number of "modes" they can be started in. Bash has four:
   1. interactive or noninteractive login shell
      Bash will read /etc/profile first, if it exists.
      If there is a .bash_profile file in user's home directory, bash will read it.
      Otherwise, if there is a .bash_login file, bash will read that one.
      Otherwise, if there is a .profile file, bash will read that one.
      At logout or exit, bash will read .bash_logout, if it exists in the user's home directory.
   2. interactive non-login shell (additional interactive shells you start from a login shell)
      Bash will read /etc/bash.bashrc first, if it exists, then .bashrc if it exists in the user's home directory.
   3. noninteractive non-login shell (when running scripts)
      If the environment variable BASH_ENV points to an existing file (after variable expansion), bash reads it, before executing the script.
   4. If Bash detects it was started by a remote user, bash will read .bashrc if it exists in the user's home directory.
   5. The command tty will output 'not a tty' if it's not a terminal session (if standard input is not connected to a terminal). Otherwise it will output the path to the terminal device it is connected to.
      Many commands and scripts use that to determine whether they can use e.g. ANSI escape sequences for changing the text color, or curses to control the entire terminal window.

In real life, you have basically three options:

1. If the service is not specific to you (your user account), but something you want to run whenever the computer is running, create a service script in /etc/init.d, and use the distribution tools to enable the service.
   Most Linux and Unix systems use a concept of runlevel to indicate what kind of service the entire computer is doing. Each runlevel has a different selection of services that are started.
   In Ubuntu, I believe the default runlevel is 2 (although you can use 2, 3, 4, and 5), and the command to manage which services run or not on which runlevel, is update-rc.d.
2. If the thing should run only whenever you are logged on to your graphical desktop (including if you happen to have a screensaver running), you should add it to your X session. The configuration files depend on which desktop you are using.
   The easiest way is to start it, use the session control panel to tell your desktop environment to save the session at logout, logout and login, and finally disable saving the session at logout.
3. If the thing should run whenever you start an interactive Bash shell -- be it via a terminal application, or via SSH --, add
   
   Code:

   [ -n "$PS1" ] && /path/to/the/script

   in .bashrc in your home directory. The other Bash startup files make sure Bash always runs that file if it exists.
   If you open up two terminal windows, the script will be run twice; once in each window. And so on.

Note that in many cases there is a serious difference between running a task, starting a task in the background, and daemonizing a task:

• Running a task (the default)
  The parent script will wait until this task finishes.
• Starting a task in the background, by adding a & at end
  The parent script will immediately continue, but when the session closes (for example, the SSH connection or the terminal window closes or you log out), the backgrounded tasks are also killed.
• Daemonizing a task
  This means the task will be detached completely from your sessions. You will be unable to directly view the task outputs, or supply it input, and must (usually) use files instead.
  You can use the screen command to create a 'screen' for the task. You can detach from it, even log out, and later on attach to the screen. See man 1 screen for details.
  I recommend this stanza to daemonize a task in Bash:
  
  Code:

  ( setsid /path/to/script </dev/null &>output & )

  where output is /dev/null if you are not interested in the script output, or a file if you are.
  service scripts have a set of predefined functions that can vary a bit between Linux distributions; Debian and Ubuntu have start_daemon (and other useful functions) in /lib/lsb/init-functions. I recommend you use an example service script as a base, modifying it to suit your needs.

I do realize how bewildering and confusing that wilderness of options is to a Linux beginner, especially to those who are used to having exactly one way of doing things dictated by Microsoft or Apple.

Truth is, the number of options makes Linux so powerful. You can twist it almost limitlessly to match your needs, after you grasp the principles and possibilities, and obtain the necessary skills. (Or you can hire someone to do it for you.)

I think it is well known that trying to change Linux into the Microsoft or Apple mould will give varying results, usually pretty far from optimal. It is a lot of work to replicate the look and feel, and the end result is simply not that amazing. Why? Because those moulds are generalisations: one way fits all. Unless you are a person who fits the generalisation perfectly, the one way will not be optimal for you.

The above is (in my experience) well known among Linux "power users", and is the reason why we will often ridicule statements of the "Linux will not become something ... until it works like Windows/OS X/foo" variety. It does not even matter whether the statement is true or not, because if things were to progress that way, we (Linux users) would lose the main strengths we get from using Linux: configurability, adaptation, versatility, freedom to do things our own way.

All this also means that if you are uninterested in molding your computer environment to fit your needs, you may be unhappy with Linux. Companies like Microsoft and Apple do spend a lot more time in getting their "one way" polished, and they will likely remain so out-of-the-box. Linux is just much more developer-driven; we care much more about what can be done with a tool, than we care what it looks like when you first unbox it.

Apologies for the possible off-topic deviations.

Hope you find this helpful,

2 members found this post helpful.

When you write a script, it needs more than the lines of what ever command or command you want to run. For example, for bash shell, your "script1" should look something like
where $HOME and $USER are set when you log in to your shell. Be carefull with the permissions and ownership if you don't want your password opn to plain text for all to see.

"#!/bin/bash" tells your shell to use the bash shell to execute the commands. Similarly, "#!/bin/sh" tells the command shell to use the default shell. To run a script within a script, look up "exec" and "source" as that may help. Also, you don't have to "open a terminal" after logging in to run a shell script.

http://tldp.org/LDP/Bash-Beginners-G...l/chap_01.html

I think there are also tools in or for Gnome and KDE to automate actions inside the desktop environment. In Ubuntu, you tell a script to run after you log in via "System>Preferences>Sessions" Also, have a look at http://code.google.com/p/autokey/

The trick to getting help on LQ is to be very clear and accurate in asking your question. Its not like we get paid to answer questions. Letting people know what it is you are trying to do without being cryptic will help you get the correct answers faster.

can you figure out the cp command to do that ?
cp command can be used to move files into protected directories !