Nytro

Advanced Bash-Scripting Guide An in-depth exploration of the art of shell scripting Version 6.3.14 13 Jul 2011 Mendel Cooper thegrendel.abs<@>gmail.com This tutorial assumes no previous knowledge of scripting or programming, but progresses rapidly toward an intermediate/advanced level of instruction . . . all the while sneaking in little nuggets of UNIX® wisdom and lore. It serves as a textbook, a manual for self-study, and a reference and source of knowledge on shell scripting techniques. The exercises and heavily-commented examples invite active reader participation, under the premise that the only way to really learn scripting is to write scripts. This book is suitable for classroom use as a general introduction to programming concepts. Download: http://bash.webofcrafts.net/abs-guide.pdf

Bash Shell Programming in Linux Copyright © 2006, P. Lutus Bash what? Okay, I grant that this page might represent a leap from the familiar to the alien without much warning. Here are some explananatory notes: Under Linux, there are some powerful tools that for all practical purposes are unavailable under Windows (I can imagine all the old Linux hands saying "Duh!"). One of these tools is something called "shell programming". This means writing code that a command shell executes. There is something like this under Windows, but as usual, the Windows version is a weak imitation. The most common Linux shell is named "Bash". The name comes from "Bourne Again SHell," which, in turn ... (imagine a lengthy recursion terminating in a caveman's grunt). There are many other shells available. Unless there is a compelling reason not to, I recommend that people stick to the Bash shell, because this increases the chance that your scripts will be portable between machines, distributions, even operating systems. I'll be showing some very basic examples of Bash shell programming on this page, and I want to say at the outset that shell programming is an art, not a science. That means there is always some other way to do the same thing. Because shell programming is an art, please don't write to say, "Wow, that was a really inefficient way to do such-and-such." Please do write (message page) to report actual errors. If this page seems too sketchy and elementary for your taste, you can choose from among the more advanced resources in this list. Online: http://www.arachnoid.com/linux/shell_programming.html

A quick guide to writing scripts using the bash shell A simple shell script A shell script is little more than a list of commands that are run in sequence. Conventionally, a shellscript should start with a line such as the following: #!/bin/bash THis indicates that the script should be run in the bash shell regardless of which interactive shell the user has chosen. This is very important, since the syntax of different shells can vary greatly. A simple example Here's a very simple example of a shell script. It just runs a few simple commands #!/bin/bash echo "hello, $USER. I wish to list some files of yours" echo "listing files in the current directory, $PWD" ls # list files Firstly, notice the comment on line 4. In a bash script, anything following a pound sign # (besides the shell name on the first line) is treated as a comment. ie the shell ignores it. It is there for the benifit of people reading the script. $USER and $PWD are variables. These are standard variables defined by the bash shell itself, they needn't be defined in the script. Note that the variables are expanded when the variable name is inside double quotes. Expanded is a very appropriate word: the shell basically sees the string $USER and replaces it with the variable's value then executes the command. We continue the discussion on variables below ... Variables Any programming language needs variables. You define a variable as follows: X="hello" and refer to it as follows: $X More specifically, $X is used to denote the value of the variable X. Some things to take note of regarding semantics: bash gets unhappy if you leave a space on either side of the = sign. For example, the following gives an error message: X = hello while I have quotes in my example, they are not always necessary. where you need quotes is when your variable names include spaces. For example, X=hello world # error X="hello world" # OK This is because the shell essentially sees the command line as a pile of commands and command arguments seperated by spaces. foo=baris considered a command. The problem with foo = bar is the shell sees the word foo seperated by spaces and interprets it as a command. Likewise, the problem with the command X=hello world is that the shell interprets X=hello as a command, and the word "world" does not make any sense (since the assignment command doesn't take arguments). Single Quotes versus double quotes Basically, variable names are exapnded within double quotes, but not single quotes. If you do not need to refer to variables, single quotes are good to use as the results are more predictable. An example #!/bin/bash echo -n '$USER=' # -n option stops echo from breaking the line echo "$USER" echo "\$USER=$USER" # this does the same thing as the first two lines The output looks like this (assuming your username is elflord) $USER=elflord $USER=elflord so the double quotes still have a work around. Double quotes are more flexible, but less predictable. Given the choice between single quotes and double quotes, use single quotes. Using Quotes to enclose your variables Sometimes, it is a good idea to protect variable names in double quotes. This is usually the most important if your variables value either (a) contains spaces or ( is the empty string. An example is as follows: #!/bin/bash X="" if [ -n $X ]; then # -n tests to see if the argument is non empty echo "the variable X is not the empty string" fi This script will give the following output: the variable X is not the empty string Why ? because the shell expands $X to the empty string. The expression [ -n ] returns true (since it is not provided with an argument). A better script would have been: #!/bin/bash X="" if [ -n "$X" ]; then # -n tests to see if the argument is non empty echo "the variable X is not the empty string" fi In this example, the expression expands to [ -n "" ] which returns false, since the string enclosed in inverted commas is clearly empty. Variable Expansion in action Just to convince you that the shell really does "expand" variables in the sense I mentioned before, here is an example: #!/bin/bash LS="ls" LS_FLAGS="-al" $LS $LS_FLAGS $HOME This looks a little enigmatic. What happens with the last line is that it actually executes the command ls -al /home/elflord (assuming that /home/elflord is your home directory). That is, the shell simply replaces the variables with their values, and then executes the command. Using Braces to Protect Your Variables OK. Here's a potential problem situation. Suppose you want to echo the value of the variable X, followed immediately by the letters "abc". Question: how do you do this ? Let's have a try : #!/bin/bash X=ABC echo "$Xabc" THis gives no output. What went wrong ? The answer is that the shell thought that we were asking for the variable Xabc, which is uninitialised. The way to deal with this is to put braces around X to seperate it from the other characters. The following gives the desired result: #!/bin/bash X=ABC echo "${X}abc" Conditionals, if/then/elif Sometimes, it's necessary to check for certain conditions. Does a string have 0 length ? does the file "foo" exist, and is it a symbolic link , or a real file ? Firstly, we use the if command to run a test. The syntax is as follows: if condition then statement1 statement2 .......... fi Sometimes, you may wish to specify an alternate action when the condition fails. Here's how it's done. if condition then statement1 statement2 .......... else statement3 fi alternatively, it is possible to test for another condition if the first "if" fails. Note that any number of elifs can be added. if condition1 then statement1 statement2 .......... elif condition2 then statement3 statement4 ........ elif condition3 then statement5 statement6 ........ fi The statements inside the block between if/elif and the next elif or fi are executed if the corresponding condition is true. Actually, any command can go in place of the conditions, and the block will be executed if and only if the command returns an exit status of 0 (in other words, if the command exits "succesfully" ). However, in the course of this document, we will be only interested in using "test" or "[ ]" to evaluate conditions. The Test Command and Operators The command used in conditionals nearly all the time is the test command. Test returns true or false (more accurately, exits with 0 or non zero status) depending respectively on whether the test is passed or failed. It works like this: test operand1 operator operand2 for some tests, there need be only one operand (operand2) The test command is typically abbreviated in this form: [ operand1 operator operand2 ] To bring this discussion back down to earth, we give a few examples: #!/bin/bash X=3 Y=4 empty_string="" if [ $X -lt $Y ] # is $X less than $Y ? then echo "\$X=${X}, which is smaller than \$Y=${Y}" fi if [ -n "$empty_string" ]; then echo "empty string is non_empty" fi if [ -e "${HOME}/.fvwmrc" ]; then # test to see if ~/.fvwmrc exists echo "you have a .fvwmrc file" if [ -L "${HOME}/.fvwmrc" ]; then # is it a symlink ? echo "it's a symbolic link elif [ -f "${HOME}/.fvwmrc" ]; then # is it a regular file ? echo "it's a regular file" fi else echo "you have no .fvwmrc file" fi Some pitfalls to be wary of The test command needs to be in the form "operand1<space>operator<space>operand2" or operator<space>operand2 , in other words you really need these spaces, since the shell considers the first block containing no spaces to be either an operator (if it begins with a '-') or an operand (if it doesn't). So for example; this if [ 1=2 ]; then echo "hello" fi gives exactly the "wrong" output (ie it echos "hello", since it sees an operand but no operator.) Another potential trap comes from not protecting variables in quotes. We have already given an example as to why you must wrap anything you wish to use for a -n test with quotes. However, there are a lot of good reasons for using quotes all the time, or almost all of the time. Failing to do this when you have variables expanded inside tests can result in very wierd bugs. Here's an example: For example, #!/bin/bash X="-n" Y="" if [ $X = $Y ] ; then echo "X=Y" fi This will give misleading output since the shell expands our expression to [ -n = ] and the string "=" has non zero length. A brief summary of test operators Here's a quick list of test operators. It's by no means comprehensive, but its likely to be all you'll need to remember (if you need anything else, you can always check the bash manpage ... ) operator produces true if... number of operands -n operand non zero length 1 -z operand has zero length 1 -d there exists a directory whose name is operand 1 -f there exists a file whose name is operand 1 -eq the operands are integers and they are equal 2 -neq the opposite of -eq 2 = the operands are equal (as strings) 2 != opposite of = 2 -lt operand1 is strictly less than operand2 (both operands should be integers) 2 -gt operand1 is strictly greater than operand2 (both operands should be integers) 2 -ge operand1 is greater than or equal to operand2 (both operands should be integers) 2 -le operand1 is less than or equal to operand2 (both operands should be integers) 2 Loops Loops are constructions that enable one to reiterate a procedure or perform the same procedure on several different items. There are the following kinds of loops available in bash for loops while loops For loops The syntax for the for loops is best demonstrated by example. #!/bin/bash for X in red green blue do echo $X done THe for loop iterates the loop over the space seperated items. Note that if some of the items have embedded spaces, you need to protect them with quotes. Here's an example: #!/bin/bash colour1="red" colour2="light blue" colour3="dark green" for X in "$colour1" $colour2" $colour3" do echo $X done Can you guess what would happen if we left out the quotes in the for statement ? This indicates that variable names should be protected with quotes unless you are pretty sure that they do not contain any spaces. Globbing in for loops The shell expands a string containing a * to all filenames that "match". A filename matches if and only if it is identical to the match string after replacing the stars * with arbitrary strings. For example, the character "*" by itself expands to a space seperated list of all files in the working directory (excluding those that start with a dot "." ) So echo * lists all the files and directories in the current directory. echo *.jpg lists all the jpeg files. echo ${HOME}/public_html/*.jpg lists all jpeg files in your public_html directory. As it happens, this turns out to be very useful for performing operations on the files in a directory, especially used in conjunction with a for loop. For example: #!/bin/bash for X in *.html do grep -L '<UL>' "$X" done While Loops While loops iterate "while" a given condition is true. An example of this: #!/bin/bash X=0 while [ $X -le 20 ] do echo $X X=$((X+1)) done This raises a natural question: why doesn't bash allow the C like for loops for (X=1,X<10; X++) As it happens, this is discouraged for a reason: bash is an interpreted language, and a rather slow one for that matter. For this reason, heavy iteration is discouraged. Command Substitution Command Substitution is a very handy feature of the bash shell. It enables you to take the output of a command and treat it as though it was written on the command line. For example, if you want to set the variable X to the output of a command, the way you do this is via command substitution. There are two means of command substitution: brace expansion and backtick expansion. Brace expansion workls as follows: $(commands) expands to the output of commands This permits nesting, so commands can include brace expansions Backtick expansion expands `commands` to the output of commands An example is given;: #!/bin/bash files="$(ls)" web_files=`ls public_html` echo "$files" # we need the quotes to preserve embedded newlines in $files echo "$web_files" # we need the quotes to preserve newlines X=`expr 3 \* 2 + 4` # expr evaluate arithmatic expressions. man expr for details. echo "$X" The advantage of the $() substitution method is almost self evident: it is very easy to nest. It is supported by most of the bourne shell varients (the POSIX shell or better is OK). However, the backtick substitution is slightly more readable, and is supported by even the most basic shells (any #!/bin/sh version is just fine) Note that if strings are not quote-protected in the above echo statement, new lines are replaced by spaces in the output. Online: http://www.panix.com/~elflord/unix/bash-tute.html

Bash Reference Manual Table of Contents Bash Features 1 Introduction 1.1 What is Bash? 1.2 What is a shell? 2 Definitions 3 Basic Shell Features 3.1 Shell Syntax 3.1.1 Shell Operation 3.1.2 Quoting 3.1.2.1 Escape Character 3.1.2.2 Single Quotes 3.1.2.3 Double Quotes 3.1.2.4 ANSI-C Quoting 3.1.2.5 Locale-Specific Translation 3.1.3 Comments 3.2 Shell Commands 3.2.1 Simple Commands 3.2.2 Pipelines 3.2.3 Lists of Commands 3.2.4 Compound Commands 3.2.4.1 Looping Constructs 3.2.4.2 Conditional Constructs 3.2.4.3 Grouping Commands 3.2.5 Coprocesses 3.3 Shell Functions 3.4 Shell Parameters 3.4.1 Positional Parameters 3.4.2 Special Parameters 3.5 Shell Expansions 3.5.1 Brace Expansion 3.5.2 Tilde Expansion 3.5.3 Shell Parameter Expansion 3.5.4 Command Substitution 3.5.5 Arithmetic Expansion 3.5.6 Process Substitution 3.5.7 Word Splitting 3.5.8 Filename Expansion 3.5.8.1 Pattern Matching 3.5.9 Quote Removal 3.6 Redirections 3.6.1 Redirecting Input 3.6.2 Redirecting Output 3.6.3 Appending Redirected Output 3.6.4 Redirecting Standard Output and Standard Error 3.6.5 Appending Standard Output and Standard Error 3.6.6 Here Documents 3.6.7 Here Strings 3.6.8 Duplicating File Descriptors 3.6.9 Moving File Descriptors 3.6.10 Opening File Descriptors for Reading and Writing 3.7 Executing Commands 3.7.1 Simple Command Expansion 3.7.2 Command Search and Execution 3.7.3 Command Execution Environment 3.7.4 Environment 3.7.5 Exit Status 3.7.6 Signals 3.8 Shell Scripts 4 Shell Builtin Commands 4.1 Bourne Shell Builtins 4.2 Bash Builtin Commands 4.3 Modifying Shell Behavior 4.3.1 The Set Builtin 4.3.2 The Shopt Builtin 4.4 Special Builtins 5 Shell Variables 5.1 Bourne Shell Variables 5.2 Bash Variables 6 Bash Features 6.1 Invoking Bash 6.2 Bash Startup Files 6.3 Interactive Shells 6.3.1 What is an Interactive Shell? 6.3.2 Is this Shell Interactive? 6.3.3 Interactive Shell Behavior 6.4 Bash Conditional Expressions 6.5 Shell Arithmetic 6.6 Aliases 6.7 Arrays 6.8 The Directory Stack 6.8.1 Directory Stack Builtins 6.9 Controlling the Prompt 6.10 The Restricted Shell 6.11 Bash POSIX Mode 7 Job Control 7.1 Job Control Basics 7.2 Job Control Builtins 7.3 Job Control Variables 8 Command Line Editing 8.1 Introduction to Line Editing 8.2 Readline Interaction 8.2.1 Readline Bare Essentials 8.2.2 Readline Movement Commands 8.2.3 Readline Killing Commands 8.2.4 Readline Arguments 8.2.5 Searching for Commands in the History 8.3 Readline Init File 8.3.1 Readline Init File Syntax 8.3.2 Conditional Init Constructs 8.3.3 Sample Init File 8.4 Bindable Readline Commands 8.4.1 Commands For Moving 8.4.2 Commands For Manipulating The History 8.4.3 Commands For Changing Text 8.4.4 Killing And Yanking 8.4.5 Specifying Numeric Arguments 8.4.6 Letting Readline Type For You 8.4.7 Keyboard Macros 8.4.8 Some Miscellaneous Commands 8.5 Readline vi Mode 8.6 Programmable Completion 8.7 Programmable Completion Builtins 9 Using History Interactively 9.1 Bash History Facilities 9.2 Bash History Builtins 9.3 History Expansion 9.3.1 Event Designators 9.3.2 Word Designators 9.3.3 Modifiers 10 Installing Bash 10.1 Basic Installation 10.2 Compilers and Options 10.3 Compiling For Multiple Architectures 10.4 Installation Names 10.5 Specifying the System Type 10.6 Sharing Defaults 10.7 Operation Controls 10.8 Optional Features Appendix A Reporting Bugs Appendix B Major Differences From The Bourne Shell B.1 Implementation Differences From The SVR4.2 Shell Appendix C GNU Free Documentation License Appendix D Indexes D.1 Index of Shell Builtin Commands D.2 Index of Shell Reserved Words D.3 Parameter and Variable Index D.4 Function Index D.5 Concept Index http://www.gnu.org/software/bash/manual/bash.html

Nu conteaza ca are motiv sau nu, poate sa vorbeasca civilizat. Va injurati cu prietenii si cu parintii daca va permit, nu aici. Pff, vorbesc ca un tata.

Sa nu va mai prind cu rahaturi ca adf.ly. Postati link-ul direct.

Dragut, dar nu trebuie sa fie "activate" (enabled) macro-urile? In 98% din cazuri nu sunt activate. Excel Options -> Trust Center -> Trust Center Settings, implicit e "Disable all macros with notification". Din cate stiu apare un mesaj care te intreaba daca sa fie rulate. Dar nu stiu cati dau "Yes". oricum, parca exista si "Sheet_Load" sau ceva asemanator si puteai pune sa se execute un cod la deschiderea fisierului Excel daca erau Macro enabled, deci nu trebuia ca victima sa apese pe ceva. Iar daca sunt activate chiar nu e necesar atata chin, cu doua linii de cod, cu URLDownloadToFile si WinExec faci ce doresti.

Da, intri in categoria celor inutili. Ban si pe acest cont.

Da, cu tricourile am vazut si eu. Dar imi plac astea, descopar si eu ce prieteni ratati pe care nu ii duce capul am...

Calmeaza-te

Tinkode nu respecta staff-ul? Nu e de capul lui. Suntem o echipa, nu face fiecare ce vrea. Si nu se ia actiuni fara a fi gandite in prealabil. Plm, baui

Cui te adresezi? "Scotei"...

O parte dintre cei care contribuie pozitiv au primit VIP. O alta parte probabil va priimi, dar cu timpul. O parte dintre cei care "contribuie negativ" au primit ban cel putin o data, altii vor primi in timp. Oricum, banurile nu se vor da aiurea.

Detalii: Eminem Killed by Romanian Malware Gang - MalwareCity : Computer Security Blog

Am facut si eu 20 intre timp.

Sunt si ei oameni, interesati de IT. Si eu am dat la STS, dar la ce examen a fost la mate-fizica... Si nu sunt politisti, se ocupa cu alte lucruri ei, nu vor sa va "agate" pe voi, nici nu ar avea de ce.

Nu e bun, e prea simplu su complet detectabil. Alternative vezi la "Programe Hack" - Spytector, Ardamax sau ce altele mai sunt.

"Powered by WordPress" Interesant...

Topic inchis.

Si el e tepar? Toata lumea "e" tepar? Adu si tu niste dovezi ceva. Sau vrei sa zici ca e vorba de aceeasi persoana: http://rstcenter.com/forum/31244-vand-realizez-jammere-bruiaz-pe-8-2-mhz.rst ?

Se da admitere la matematica (alegere dintre algebra, analiza si geometrie cred) si informatica. Parca un singur examen cu mate-info a fost. Se intra si cu 5.05, cam asa. Adica nu dau foarte multi si pica destui.

Inchis, daca e vreo problema -> PM.

"God" - SysOp-ul, e baiat destept, nu cred ca e un pusti de 12 ani. Poti vorbi cu el, probabil vei avea VIP+, deci nu iti faci griji cu ratia.

Instant Messaging digsby is a multiprotocol IM client that lets you chat with all your friends on AIM, MSN, Yahoo, ICQ, Google Talk, and Jabber with one simple to manage buddy list. Email Notifications digsby is an email notification tool that alerts you of new email and lets you perform actions such as 'Delete' or 'Report Spam' with just one click. Social Networking digsby is a social networking tool that alerts you of events like new messages and gives you a live Newsfeed of what your friends are up to. Video: http://www.youtube.com/watch?v=16grAzndW9w Download: http://www.digsby.com/

Firefox are probleme mari cu dezalocarea memoriei. Deschizi si tu 7 tab-uri, le inchizi, ramai cu o singura pagina de 3 KB deschisa si te trezesti ca iti mananca 170 MB de memorie. Firefox e util daca te folosesti de pluginuri mai ales, sau daca ai nevoie de setari mai avansate. Desi eu folosesc Firefox, recomand Chrome.