Friday, 2 October 2015

Bash - how to get argument & user input

Pass argument:
To input arguments into a Bash script, like any normal command line program, there are special variables set aside for this
The arguments are stored in variables with a number in the order of the argument starting at 1
  • First Argument: $1
  • Second Argument: $2
  • Third Argument: $3
  • Example
    • command: ./script.bash alpha beta gamma
    • Variables: $1=='alpha'; $2=='beta'; $3=='gamma'

The variable $0 is the script's name. The total number of arguments is stored in $#. The variables $@ and $* return all the arguments.
For more complicated examples, you might consider getopt:

Script Example

echo "the $1 eats a $2 every time there is a $3"
echo "bye:-)"
  • Command: ./script.bash dog bone moose
  • Output:
    the dog eats a bone every time there is a moose

Get user input:


We looked at one form of user input (command line arguments) in the previous section. Now we would like to introduce other ways the user may provide input to the Bash script. Following this we'll have a discussion on when and where is best to use each method.
After the mammoth previous section this one is much easier to get through.

Ask the User for Input

If we would like to ask the user for input then we use a command called read. This command takes the input and will save it into a variable.
read var1
Let's look at a simple example:

  1. #!/bin/bash
  2. # Ask the user for their name

  3. echo Hello, who am I talking to?

  4. read varname

  5. echo It\'s nice to meet you $varname
Let's break it down:
  • Line 4 - Print a message asking the user for input.
  • Line 6 - Run the command read and save the users response into the variable varname
  • Line 8 - echo another message just to verify the read command worked. Note: I had to put a backslash ( \ ) in front of the ' so that it was escaped.
  1. ./
  2. Hello, who am I talking to?
  3. Ryan
  4. It's nice to meet you Ryan

  • Note: Ryan above is in italics just to show that it was something I typed in. On your terminal input will show up normally.

More with Read

You are able to alter the behaviour of read with a variety of command line options. (See the man page for read to see all of them.) Two commonly used options however are -p which allows you to specify a prompt and -s which makes the input silent. This can make it easy to ask for a username and password combination like the example below:

  1. #!/bin/bash
  2. # Ask the user for login details

  3. read -p 'Username: ' uservar
  4. read -sp 'Password: ' passvar
  5. echo
  6. echo Thankyou $uservar we now have your login details
  • On lines 4 and 5 above we include the prompt within quotes so we can have a space included with it. Otherwise the user input will start straight after the last character of the prompt which isn't ideal from a readability point of view.
  1. ./
  2. Username: ryan
  3. Password:
  4. Thankyou ryan we now have your login details

More variables

So far we have looked at a single word as input. We can do more than that however.

  1. #!/bin/bash
  2. # Demonstrate how read actually works

  3. echo What cars do you like?

  4. read car1 car2 car3

  5. echo Your first car was: $car1
  6. echo Your second car was: $car2
  7. echo Your third car was: $car3

Tuesday, 29 September 2015

Cron expression visit again for Jenkins

When specify "Poll SCM", we can specify a schedule via cron expression:

This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:
MINUTEMinutes within the hour (0–59)
HOURThe hour of the day (0–23)
DOMThe day of the month (1–31)
MONTHThe month (1–12)
DOWThe day of the week (0–7) where 0 and 7 are Sunday.
To specify multiple values for one field, the following operators are available. In the order of precedence,
  • * specifies all valid values
  • M-N specifies a range of values
  • M-N/X or */X steps by intervals of X through the specified range or whole valid range
  • A,B,...,Z enumerates multiple values
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
The H symbol can be used with a range. For example, H H(0-7) * * * means some time between 12:00 AM (midnight) to 7:59 AM. You can also use step intervals with H, with or without ranges.
The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project.
Beware that for the day of month field, short cycles such as */3 or H/3 will not work consistently near the end of most months, due to variable month lengths. For example, */3 will run on the 1st, 4th, …31st days of a long month, then again the next day of the next month. Hashes are always chosen in the 1-28 range, so H/3 will produce a gap between runs of between 3 and 6 days at the end of a month. (Longer cycles will also have inconsistent lengths but the effect may be relatively less noticeable.)
Empty lines and lines that start with # will be ignored as comments.
In addition, @yearly@annually@monthly@weekly@daily@midnight, and @hourly are supported as convenient aliases. These use the hash system for automatic balancing. For example, @hourly is the same as H * * * * and could mean at any time during the hour. @midnight actually means some time between 12:00 AM and 2:59 AM.
# every fifteen minutes (perhaps at :07, :22, :37, :52)
H/15 * * * *
# every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24)
H(0-29)/10 * * * *
# once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM)
H 9-16/2 * * 1-5
# once a day on the 1st and 15th of every month except December
H H 1,15 1-11 *

Backspace in insert mode in vi doesn't erase the character

I am new to vi, actually I have started learning vi from today and I have got stuck at the behavior of the backspace key.
Actually when I fired up vi on my Ubuntu 12.04 for the first time my backspace key was working normally but after that it has started behaving strangely. Whenever I press the backspace in the insert mode it just moves one place to the left instead of erasing the character.
How can I get back the default backspace functionality?

Here is the perfect solution open the terminal, go to home directory and type:
N.B 1>this only works for vim , NOT vi.
2>.vimrc file has to be created under ~ folder which is your user's folder. Under cygwin it's normally /cygdrive/c/Users/<>

$ vim ~/.vimrc
a new file open now add these lines to the file and exit by saving
set nocompatible
set backspace=2

What is the difference between vi and vim?

Functionally, vim is almost a proper superset of vi. Therefore, everything that is in vi is available in vim.
Vim adds onto those features. Here are a some of the extended vim features:
  • Vim has been ported to a much wider range of OS's than vi.
  • Vim includes support (syntax highlighting, code folding, etc) for several popular programming languages (C/C++, Python, Perl, shell, etc).
  • Vim integrates with cscope.
  • Vim can be used to edit files using network protocols like SSH and HTTP.
  • Vim includes multilevel undo/redo.
  • Vim allows the screen to be split for editing multiple files.
  • Vim can edit files inside a compressed archive (gzip, zip, tar, etc).
  • Vim includes a built in diff for comparing files (vimdiff).
  • Vim includes support for plugins, and finer control over config and startup files.
  • Vim can be scripted with vimscript, or with an external scripting language (e.g. python, perl, shell).
There are many more differences. Refer below sources which are few of good places to start finding out more.


Sunday, 27 September 2015

deauth attack

Realistically, you cannot stop a bad guy from sending deauthentication packets.
Instead, you should focus on ensuring you are resilient to a deauth attack. Make sure your network is configured in a way that the deauth attack doesn't enable an attacker to compromise your network.
To do that, you need to make sure you are using WPA2. If you are using a pre-shared key (a passphrase), make sure the passphrase is very long and strong. If it is not already, change it immediately! If you are not using WPA2, fix that immediately!
The primary reason why bad guys send deauth packets is that this helps them execute a dictionary attack against your passphrase. If a bad guy captures a copy of the initial handshake, they can try out various guesses at your passphrase and test whether they are correct. Sending a deauth packet forces the targeted device to disconnect and reconnect, allowing an eavesdropper to capture a copy of the initial handshake. Therefore, standard practice of many attackers who might try to attack your wireless network is to send deauth packets. If you are seeing many deauth packets, that is a sign that someone may be trying to attack your wireless network and guess your passphrase.
Once the attacker has sent a deauth packet and intercepted the initial handshake, there are tools and online services that automate the task of trying to recover the passphrase, by guessing many possibilities. (See, e.g., CloudCracker for a representative example.)
The defense against this kind of attack is to ensure your passphrase is so long and strong that it cannot possibly be guessed. If it's not already long and strong, you need to change it right away, because someone is probably trying to guess it as we speak.
(The other reason a bad guy might send deauth packets is as an annoyance. However, as most users probably won't even notice, it's not a very effective annoyance.)
To learn more, see these resources:
Short version:

WPA2 authentication is performed through a four-way handshake. Instead of just sending your password in plaintext to any access point you connect to, this handshake ensures that unless both parties already know the password, the password (or any attempt at it) is not revealed. However, enough of that four-way handshake can be recovered to make offline password cracking possible.


Total visitors since Jan 2012

World Visitor Map