A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://ryanstutorials.net/bash-scripting-tutorial/bash-input.php below:

User Input - Bash Scripting Tutorial

User Input!

Let's make our scripts interactive.

Introduction

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:

introduction.sh
  1. #!/bin/bash
  2. echo Hello, who am I talking to?
  3. read varname
  4. echo It\'s nice to meet you $varname

Let's break it down:

  1. ./introduction.sh
  2. Hello, who am I talking to?
  3. Ryan
  4. It's nice to meet you Ryan
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:

login.sh
  1. #!/bin/bash
  2. read -p 'Username: ' uservar
  3. read -sp 'Password: ' passvar
  4. echo
  5. echo Thankyou $uservar we now have your login details
  1. ./login.sh
  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.

cars.sh
  1. #!/bin/bash
  2. echo What cars do you like?
  3. read car1 car2 car3
  4. echo Your first car was: $car1
  5. echo Your second car was: $car2
  6. echo Your third car was: $car3
  1. ./cars.sh
  2. What cars do you like?
  3. Jaguar Maserati Bentley
  4. Your first car was: Jaguar
  5. Your second car was: Maserati
  6. Your third car was: Bentley
  7. ./cars.sh
  8. What cars do you like?
  9. Jaguar Maserati Bentley Lotus
  10. Your first car was: Jaguar
  11. Your second car was: Maserati
  12. Your third car was: Bentley Lotus

The general mechanism is that you can supply several variable names to read. Read will then take your input and split it on whitespace. The first item will then be assigned to the first variable name, the second item to the second variable name and so on. If there are more items than variable names then the remaining items will all be added to the last variable name. If there are less items than variable names then the remaining variable names will be set to blank or null.

Reading from STDIN

It's common in Linux to pipe a series of simple, single purpose commands together to create a larger solution tailored to our exact needs. The ability to do this is one of the real strenghs of Linux. It turns out that we can easily accommodate this mechanism with our scripts also. By doing so we can create scripts that act as filters to modify data in specific ways for us.

Bash accomodates piping and redirection by way of special files. Each process gets it's own set of files (one for STDIN, STDOUT and STDERR respectively) and they are linked when piping or redirection is invoked. Each process gets the following files:

To make life more convenient the system creates some shortcuts for us:

fd in the paths above stands for file descriptor.

So if we would like to make our script able to process data that is piped to it all we need to do is read the relevant file. All of the files mentioned above behave like normal files.

summary
  1. #!/bin/bash
  2. echo Here is a summary of the sales data:
  3. echo ====================================
  4. echo
  5. cat /dev/stdin | cut -d' ' -f 2,3 | sort

Let's break it down:

  1. cat salesdata.txt
  2. Fred apples 20 August 4
  3. Susy oranges 5 August 7
  4. Mark watermelons 12 August 10
  5. Terry peaches 7 August 15
  6. cat salesdata.txt | ./summary
  7. Here is a summary of the sales data:
  8. ====================================
  9. apples 20
  10. oranges 5
  11. peaches 7
  12. watermelons 12
So which should I use?

So we now have 3 methods for getting input from the user:

Which method is best depends on the situation.

You should normally favor command line arguments wherever possible. They are the most convenient for users as the data will be stored in their command history so they can easily return to it. It is also the best approach if your script may be called by other scripts or processes (eg. maybe you want it to run periodically using CRON).

Sometimes the nature of the data is such that it would not be ideal for it to be stored in peoples command histories etc. A good example of this is login credentials (username and password). In these circumstances it is best to read the data during script execution.

If all the script is doing is processing data in a certain way then it is probably best to work with STDIN. This way it can easily be added into a pipeline.

Sometimes you may find that a combination is ideal. The user may supply a filename as a command line argument and if not then the script will process what it finds on STDIN (when we look at If statements we'll see how this may be achieved). Or maybe command line arguments define certain behaviour but read is also used to ask for more information if required.

Ultimatately you should think about 3 factors when deciding how users will supply data to your Bash script:

Summary
read varName
Read input from the user and store it in the variable varName.
/dev/stdin
A file you can read to get the STDIN for the Bash script
Usability
Your choice of input methods will have an impact on how useable your script is.
Activities

Let's dabble with input.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4