LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 07-06-2011, 12:45 AM   #16
IlbiStarz
LQ Newbie
 
Registered: Jul 2011
Posts: 18

Original Poster
Rep: Reputation: Disabled

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?)
 
Old 07-06-2011, 12:52 AM   #17
frieza
Senior Member
 
Registered: Feb 2002
Location: harvard, il
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
Posts: 3,219

Rep: Reputation: 399Reputation: 399Reputation: 399Reputation: 399
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.

Last edited by frieza; 07-06-2011 at 12:55 AM.
 
1 members found this post helpful.
Old 07-06-2011, 12:53 AM   #18
TheIndependentAquarius
Senior Member
 
Registered: Dec 2008
Posts: 4,680
Blog Entries: 29

Rep: Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917
Yes, I'll correct my post w.r.t. dir.
 
Old 07-06-2011, 12:54 AM   #19
kingbeowulf
Member
 
Registered: Oct 2003
Location: WA
Distribution: Slackware64 14.2 Slackware 14.2, Slackware{32,64}-current
Posts: 774
Blog Entries: 2

Rep: Reputation: 256Reputation: 256Reputation: 256
Quote:
Originally Posted by IlbiStarz View Post
5. I don't have time to read right now sorry, I need to get this working in 2 days!
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:
Quote:
Installing custom init-scripts

To install your own script, copy it to /etc/init.d, and make it executable.

sudo cp myscript /etc/init.d
sudo chmod +x /etc/init.d/myscript

To make the script run with the start argument at the end of the start sequence, and run with the stop argument at the beginning of the shutdown sequence:

sudo update-rc.d myscript defaults 98 02

98 and 02 are the start and stop sequence numbers respectively. Both are numbers between 00 and 99 and specify how early or late a service is started or killed. If a service is started late, it should be killed early and vice-versa. A good rule of thumb is to make the stop sequence number equal to 100 minus the start sequence number.

For more information on the usage of update-rc.d

man update-rc.d

IconsPage/IconWarning3.png
 
Old 07-06-2011, 01:04 AM   #20
IlbiStarz
LQ Newbie
 
Registered: Jul 2011
Posts: 18

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by beowulf999 View Post
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
 
Old 07-06-2011, 01:15 AM   #21
IlbiStarz
LQ Newbie
 
Registered: Jul 2011
Posts: 18

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by beowulf999 View Post
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:
I just did this, but nothing happens when I reboot.
 
Old 07-06-2011, 01:19 AM   #22
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.9, Centos 7.3
Posts: 17,374

Rep: Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383
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
Code:
.bash_profile
for bootup, add to
Code:
/etc/rc.local
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.
 
Old 07-06-2011, 01:21 AM   #23
IlbiStarz
LQ Newbie
 
Registered: Jul 2011
Posts: 18

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by chrism01 View Post
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
Code:
.bash_profile
for bootup, add to
Code:
/etc/rc.local
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... :/
 
Old 07-06-2011, 05:51 AM   #24
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Rep: Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721
Quote:
Originally Posted by IlbiStarz View Post
3. Don't I have to login for it to run? See I know nothing about Linux
Uhh I am going to be disabling login, so I'm guessing when it boots?
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/
 
Old 07-06-2011, 11:47 PM   #25
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.9, Centos 7.3
Posts: 17,374

Rep: Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383Reputation: 2383
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 ... )
 
Old 07-06-2011, 11:55 PM   #26
IlbiStarz
LQ Newbie
 
Registered: Jul 2011
Posts: 18

Original Poster
Rep: Reputation: Disabled
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
 
Old 07-07-2011, 12:41 AM   #27
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 946Reputation: 946Reputation: 946Reputation: 946Reputation: 946Reputation: 946Reputation: 946Reputation: 946
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.
Old 07-08-2011, 01:27 AM   #28
kingbeowulf
Member
 
Registered: Oct 2003
Location: WA
Distribution: Slackware64 14.2 Slackware 14.2, Slackware{32,64}-current
Posts: 774
Blog Entries: 2

Rep: Reputation: 256Reputation: 256Reputation: 256
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
Code:
#!/bin/bash
#
exec $HOME/script --user=$USER --pass=pass --host=host --port=8332 --device=0
..etc...
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.
 
Old 07-08-2011, 01:51 AM   #29
dEnDrOn
Member
 
Registered: Jun 2011
Location: oMNipre$ent
Distribution: fedora
Posts: 510
Blog Entries: 12

Rep: Reputation: Disabled
Quote:
Originally Posted by IlbiStarz View Post
Any help on how to move the file?
can you figure out the cp command to do that ?
cp command can be used to move files into protected directories !
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
dow copy copy-protected cds with dd commant gh_D_ir Linux - Software 4 04-01-2011 04:41 PM
CLI copy is greater than GUI copy ?? 0_o killahsmurf Slackware 14 01-04-2006 11:53 AM
boot error after using Copy Commander to copy debian system onto larger new drive Interceptor Linux - Hardware 7 05-04-2003 12:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 02:14 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration