Use of getopt command in linux

It is observerd that there are many students and many people who create their own commands, it is more obvious that they create their commands according to the user satisfaction and theri ease. So many commands use the getopt command to create their own commands with particular options. 

Shells in Linux

A shell is a command-line interpreter or shell that provides a traditional user interface for the UNIX operating system and for Unix-like systems. Users direct the operation of the computer by entering commands as text for a command line interpreter to execute or by creating text scripts of one or more such commands. The versatility of the command-line shell is what really allows this, but what makes each shell different and why do people prefer one over another?

 Fig1: Shells in Linux

The most influential UNIX shells have been the Bourne shell and the C shell. The Bourne shell, sh, was written by Stephen Bourne at AT&T as the original UNIX command line interpreter; it introduced the basic features common to all the UNIX shells, including piping, here documents, command substitution, variables, control structures for condition-testing and looping and filename wildcarding. The language, including the use of a reversed keyword to mark the end of a block, was influenced by ALGOL 68. The C shell, csh, was written by Bill Joy while a graduate student at University of California, Berkeley. The language, including the control structures and the expression grammar, was modeled on C. The C shell also introduced a large number of features for interactive work, including the history and editing mechanisms, aliases, directory stacks, tilde notation, cdpath, job control and path hashing.

Users typically interact with a modern UNIX shell using a terminal emulator. Common terminals include xterm and GNOME Terminal. Both shells have been used as coding base and model for many derivative and work-alike shells with extended feature sets.

What Do Shells Do?

The command-line is a very interesting thing. Once considered to be the most advanced user interface, it has gone the way of waistcoats and fountain pens: shunned to the periphery. While you still see much of the purpose and utility in them, they’re usually left aside primarily for enthusiasts to appreciate, mainly because they spend the time to learn the ins and outs of them. Indeed, the command-line in any given operating system will have a lot of quirks because easy OS interprets commands differently. Today, this is mainly an issue between Linux, OS X, and Windows, but before this was a problem with most computers.

 Fig2: Shell types

Shells entered the picture and allowed a more standard extension of the command-line in a way that was much more inconspicuous. Shells added a lot of functionality, such as command and file name completion and more advanced scripting abilities, and helped bring some performance enhancements. They also did a lot to cover some annoying problems. For example, in Unix, you couldn’t back up through symlinks to the directories before you followed them. All in all, they added some features that allowed users to get their jobs done more quickly and efficiently, just like Linux’s plethora of alternative Window Managers.

Why Are There So Many?

The most prominent progenitor of modern shells is the Bourne shell – known as ‘sh’ – which was named after its creator Stephen Bourne who worked at AT&T. It became the default UNIX command-interpreter because of its support for command substitution, piping, variables, condition-testing, and looping, along with other features. This was in an era that programming really went along with using the command-line, a practice that many argue has been diluted today. It did not offer users much leeway in customizations for users, such as aliases, command completion and shell functions.

Fig3: Shell varieties

C shell (‘csh’) was developed Bill Joy at UCB and really shook things up. It added a lot of interactive elements that users could use to control their systems, like aliases (shortcuts for long commands), job management abilities, command history, and more. It was modeled off of the C programming language, an interesting idea because UNIX was written in C. It also meant that users of the Bourne shell had to learn C so they could enter commands in it. In addition, it had tons of bugs which had to be hammered out by users and creators alike over a large period of time. People ended up using the Bourne shell for scripts because it handled non-interactive commands better, but stuck with the C shell for normal use.

Over time, lots of people fixed the bugs in and added features to the C shell, culminating in something called ‘tcsh’. The problem, then, was that in distributed Unix-based computers, csh was still the default, and had some added “non-standard” features added in, creating a very fragmented mess of things (in retrospect). Then, David Korn from AT&T worked on the Korn shell – ‘ksh’ – which tried to mitigate the situation by using the Bourne shell’s language as a basis, but added in all of the new features that everyone was accustomed to. Unfortunately for many, it wasn’t free.

 Fig4: tcsh

Another response to the hectic proprietary csh implementations was the Portable Operating System Interface for UNIX, or POSIX. It was a successful attempt at creating a standard for command interpretation and eventually mirrored a lot of the features that the Korn shell had. Simultaneously, the GNU project was going on and was an attempt at creating a free operating system that was completely Unix-compatible. It developed a shell for its own purpose: the Bourne Again shell, formed by bashing together features from sh, csh, and ksh. The result, as seen in retrospect, was pretty impressive.

Kenneth Almquist created a Bourne shell clone – ‘ash’ – that was POSIX-compatible and would become the default shell in BSD, a different branch/clone of UNIX. Its uniqueness is that it’s really lightweight, so it became extremely popular in embedded-Linux systems. If you have a rooted Android phone that has Busy Box installed, it’s using code from ash. Debian developed a clone based on ash called ‘dash’.

 

Fig5: Ash

One of the most prominent of “new” shells is ‘zsh’, developed by Paul Falstad in 1990. It’s a Bourne-style shell that takes features from bash and previous shells and adds even more features. It has spell-checking, the ability to watch for logins/logouts, some built-in programming features like bytecode, support for scientific notation in syntax, allows for floating-point arithmetic, and then some. Another is the Friendly Interactive Shell, ‘fish’, which focuses on command syntax that’s easy to remember and use.

On the whole, most shells were created as clones of previous shells that added functionality, fixed bugs, and bypassed licensing issues and fees. The notable exceptions are the original Bourne shell and the C shell, and both rc shell and ash which aren’t entirely original but definitely have some niche-utility.

Which Should I Use?

With so many out and about, you’d think that it’s hard to choose which shell to use, but it’s actually not very difficult. Since so many are based off of Bourne shell, basic things will be the same between most shells.

 Fig6: Shell choices

Bash is the most widely used shell out there and is the default for most Linux distributions. It’s really robust and has tons of features, most of which you probably won’t use unless you program, so it’s pretty safe to say you can stick to this one. Because it’s so common, it’s perfect for scripting things that will be used across different platforms. If you want to try something different that’s a little more user-friendly, you can try out fish instead.

If you tinker with embedded-Linux systems a lot, like to put Linux on ridiculous things like your Nintendo DS, or you really like Debian, then ash/dash is probably best suited for you. Again, it works mostly like the others, but since it’s sort of bare-bones and light-weight, you’ll find some more complicated functionality missing.

Fig7: Zsh

If you plan on programming or learning to develop on the command-line, then you’ll have to be a little choosier. Bash is a fine choice, but I know enough people who have switched to Zsh for its extras. I guess it really depends on how complicated your projects will get and what type of functionality you prefer from your shell. Some people still stick to tcsh because they know and use C regularly and it’s easier for them. Odds are that if you’re not sure which shell to choose, you probably don’t program much, so try to choose something that will line up with what you want to learn and do some research on what others in that field use.

You can easily install and remove different shells using the Software Center on Ubuntu or your preferred package manager. Shells are located in the /bin/ directory, and as long as you’re running a modern Linux distribution, it’s easy to change what your default is. Just enter the following command:

• chsh

You’ll be prompted for your password, and then you can change to a different shell by entering its path.

 

Fig8: Chsh 

In square brackets, you’ll see your current default, and if you want to leave it as-is, just hit Enter.

So guys, which shells you use or prefer? Do comment.

Check if you are running 32bit OS/CPU or 64 bit OS/CPU on your Linux Machine

Hi Linux Users, I will elaborate some basic tricks to know your CPU configuration on your Linux System. Many times I had came across a unique question from Linux Users that how should I know that I am using 32 bit CPU/OS or 64 bit CPU/OS? Definitely I am here to know you answer for this question but before that we have to understand some points. They are as follows.

   1.    We can run 32 bit operating system on 64 bit CPU.

   2.     We can run 64 bit operating system on 64 bit CPU.

   3.    We cannot run  64 bit operating system on 32 bit CPU.

   4.  We can run 32 bit operating system on 32 bit CPU.

Once we are clear with these points now we are ready to check of our CPU is  32 bit or 64 bit.

How to check if CPU is 64 bit supported or not, basically there are two ways:-

1.Method I:-

Use lscpu command to check if it supports multiple CPU operation modes(either 16, 32 or 64 bit mode).

Fig.1 lscpu command

As a normal/root user execute below command

     lscpu | grep op-mode

Sample output on a 32-bit processor

Fig.2 Using lscpu with grep

If you observe the first output will say that your CPU supports both 32-bit as well as 64 bit operating systems. This indicates that its 64-bit processor from our above 4 rules. But in the second machine it says only 32-bit CPU mode which indicates its a 32 bit processor.

Method 2:-

Use proc file system, CPU info to get the processor type.

   grep -w lm /proc/cpuinfo

Sample output on a 32-bit processor when searching for lm(long mode) bit is set or not.

Fig.3 Checking for Long mode

If you dont get any output that indicates its not a 32 bit processor.

How to check if my Operating system is a 64-bit or 32-bit?

Before knowing about this you should know about i386, i486 etc naming convention.

What is difference between i386, i486, i586, and i686 OS?

They are the names given by software industry to some softwares for different Intel architectures. If we say i386, its Intel 80386 processor, also known as the i386, or just 386, is a 32-bit microprocessor introduced by Intel in 1985. If I say i486 it is an Intel 80486, i586 is a 80586 and i686 is a 80686 processor. In short they are called as x86 family which are of 32 bit processor. And for 64 bit OS you will get x86_64.

Option 1: check with uname command if your OS is 32 bit or 64 bit. 

   uname -m

Fig.4 checking Architecture with uname

   uname -p

Fig.5 checking Architecture with uname

Option 2: Check with lscpu command as below.

   lscpu | grep -i arch

Fig.6 Checking Architecture with lscpu command

Option 3: Check with getconf command as shown below

    getconf LONG_BIT

Sample output for 32 bit OS

Fig.7 Checking CPU configuration in Bits

Please let us know if you know any other way to get OS and Processor processing bit details.