Linux - NewbieThis 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!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
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.
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.
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
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.
*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
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
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.
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.
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.
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.
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:
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.
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.
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.
If Bash detects it was started by a remote user, bash will read .bashrc if it exists in the user's home directory.
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:
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.
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.
If the thing should run whenever you start an interactive Bash shell -- be it via a terminal application, or via SSH --, add
[ -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:
( 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.
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.
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.