Expose the power of Bash shell, tutorial here.
Bash Shell and Beyond
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Expose the power of Bash shell, tutorial here.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why is it that we cannot develop a more powerful default shell than sh and its variants?
Have you ever tried to write even moderately complex scripts in sh? ACK. This is why people use perl,python,ruby, ANYTHING but sh. Just for fun, try writing a moderate perl script in sh….warning, keep shap objects away from yourself during this exercice.
sh and its variants need to die. Take ‘make’ with them. Its hard for unix heads to admit that some of their tools are crap, but sh and make are two of the very very worst.
Here’s a novel concept – make python the default shell. Or perl. Or ANYTHING moderately well conceived. Or are we saying we are so stuck in the 70s that we refuse to change?
Fair play, sh is showing it’s age. But this is UNIX, one size does not fit all. Want a different default shell? You can have one! Want to write a script in perl, python, ruby or whatever? You can and still ‘launch’ it from sh with a #!/usr/bin/<insert favourite interpreter>.
Bash is default on Linux boxes, and pdksh is installed on the BSDs by default. csh and ksh are pretty much always on HPUX and Solaris, I’d guess for other OS’s too. So there’s no need to suffer sh if you don’t want to.
voila:
http://unixnaut.com/skills/Languages/python/pysh.html
The wonders of the internet…any wacky thing you come up with has been done by somebody.
Have you ever tried to write even moderately complex scripts in sh? ACK
Maybe the shell wasn’t designed to write even moderately complex scripts? As a Windows user used to batch files, I am envious that you guys have a default shell as powerful as it is.
As for replacing it, I dunno the pros and cons of doing so. Perhaps the default shell is just faster?
Why not make Python the shell? Because it’d be an absolutely useless interactive shell – it’s not designed to be an interactive environment, even if it can fill that function. Do you really want to type something like:
os.spawnvp (os.P_WAIT, “ls”, [“ls”, “-l”, “/usr/bin”])
each time you want to run a program. How do you redirect stdout to a log file in Python? It’s a lot more complicated than simply “> file”
In contrast, bash and friends are designed as an interactive environment for running programs. Their scripting functions, while less powerful, are designed to support that role. And for scripts where running other programs is the primary role, it really is a better choice than anything else.
Use the right tool for the task. Python’s a great language that I use for most tasks that involve evaluating and processing data, but it’s generally not the right choice for a program that deals primarily with running other programs. That’s where a traditional shell is strong.
eshell.el
As a zsh user, I was always surprised it was smaller (executable-wise) than bash. I guess I always thought it was the fattest of all the shells.
And, I’m happy to say I have only one system now that I have to use tcsh on. Just one left…
Correction: tcsh is the primary shell in FreeBSD.
In any case, there’s no reason to force one tool to do all jobs. It’s fine to have Ruby/Perl/Python run your complex scripts, sh handle simple scripts, and tcsh/pdksh/zsh/etc. as your interactive shell.
Bash isn’t meant to write complex scripts in and is typically used as a scripter of scripting languages.
What really needs to be thrown out the window is the clusterf*ck that are the autotools.
Wait till Monad is shipped. Once its out there, the biggest weakness of windows will be changed to its biggest strength once and for all.
You will not want any bash, sh, ksh, tsh and so on after that.
http://clisp.cons.org/clash.html
Correction: FreeBSD’s default interactive shell is tcsh. The sh shell is used for scripts and is used because scripts written for it are portable to any system with a POSIX.2 compliant command interpreter. Sh is most similar to the bourne or korn shells than it is to a C shell. Sh isn’t meant for interactive use.
Using bash for scripting is considered an act of evil in many circles (bashisms suck). I like it for interative use though.
I had assumed that the tutorial was going to be appropriate to someone new to bash scripting. As such, I was completely lost. The article seems to be aimed more at people who are already familiar with the language.
This series is meant for beginners:
http://linuxreviews.org/beginner/Bash-Beginners-Guide/
http://linuxreviews.org/beginner/Bash-Scripting-Introduction-HOWTO/
http://linuxreviews.org/beginner/abs-guide/
http://linuxreviews.org/beginner/bash_GNU_Bourne-Again_SHell_Refere…
http://linuxreviews.org/beginner/tao_of_regular_expressions/
Yes, it’s for people who can navigate through ‘man bash’. 🙂
You need some C programming background also, because my patch adds new features to Bash shell through C extensions. You can get a preview of my articles in LinuxGazette.net from http://home.eol.ca/~parkw/index.html . I already submitted December and January articles, and they have more “meat”.
I’m reasonably able at shell programming and still feel lost with this article. It feels like I opened a book in the middle, without any reasonable introduction or context to what it’s trying to convey. Is it a lesson in advanced bash, in C string functions, or in something else? Which commands apply to bash and which to the ‘something else’?
The fact that most people here simply toss out comments telling me that bash is for the prompt and perl is for scripting simply tells me that you have used broken tools for so long that you think they are the norm.
There is NO REASON why your shell prompt language and your scripting language should be distinct.
NO REASON. It is only your mental handicap that keeps them separate.
Right…
luckily we have you to enlighten us.
Writing big letters don’t turn statements into facts, did you know that?
It’s about adding features to Bash. There are things you can do easily in shell, and things that are difficult to do. I’m trying to have more things included in “easy” domain, by borrowing features in Awk, Python, Zsh, Ksh, and functional languages. Also, just as you can write Python wrapper, say for XML parser or SQL database, you can do the same in Bash shell. It’s much easier, since Bash internal is just pure C.
Bash is absolutely fine in my book, great for most of my shell scripting needs, and handles some of the content of my web page, such as some interactive stuff I have. Anything more complex I leave to PERL and PHP. Python can jump off a cliff for all I care ;P, Bash it self is a quite powerful tool.
Could I use it to write.. say a GuestBook for a webpage? Yes. Would I? No. I’d do it in PHP.
Lumbergh:
What really needs to be thrown out the window is the clusterf*ck that are the autotools.
I could not agree with you more.
/2 cents
Wait till Monad is shipped. Once its out there, the biggest weakness of windows will be changed to its biggest strength once and for all.
You will not want any bash, sh, ksh, tsh and so on after that.
I love hearing this crap constantly from the Windows crowd. At this point Monad is vaporware. There is no point in claiming its superiority when it does not even exist yet. It’s especially stupid to do so when we know all about Microsoft’s penchant for delays and outright dropping features.
@ Abraxas: If Monad is vaporware, then why do I have it installed on my machine?
Monad looks great, but it is too much of a programming language for my taste. It lacks must easy to understand en quick DOS commands, and it lacks the support of basic tools like a (streaming) text editor or a mail client.
Still the foundations of Monad are really innovative. Just pass objects through pipes, sort them, and export them to a spreadsheet file is just one line of code.
At this point Monad is vaporware.
Vapourware that you can download the beta version of 😉
…When you don’t use Windows. I’m not installing Windows ever again if I can get away with it. Unix may be perceived to be old, but it’s foundations are pretty solid.
Unix may not be everyone’s cup of tea. Therefore there are other non-Unix systems out there. I would welcome a good Shell on Windows. Every computeruser deserves good tools, but don’t asume that just because Windows gets a Shell (finally) all us Unixheads are going to drop our favourite bash, ash, korn, tsh, csh, ad infinitum.
Powerful Unix shells do what is needed and provide a comfortable and learnable interface to your system.
>>Just pass objects through pipes, sort them,
>>and export them to a spreadsheet file is
>>just one line of code.
Yeah, but are we talking about a very very very very very long line of code or what?
As it is, if you’d take the few minutes to google for bash docs, and add together some of the tutorials, helps, mans, faqs, examples, books and whatnot from let’s say the last 7-8 years… well, let’s not try to guess how many thousand pages of top ranking material would you be able to extract from those. And I needn’t guess that there are plenty for-newbie docs too.
Just remember, unix wasn’t the OS of the lame non-tech-savvy people. It was developed by real developers for real developers. Fortunately linux still retaines aspects of that time. That’s why I use it. Meaning not every information is always spoonfed.
That has been changing in the past years, which is good because some monopoly we are used to hate can be a bit tickled
and the people can be acquainted with a powerful yet still free to use O.S.
> Meaning not every information is always spoonfed.
There’s a difference between spoonfeeding information and writing in a logical manner that makes sense. If I was to write an article consisting purely of code without any explanation then could I excuse it as l33t information for l33ts? No, because what I had presented simply isn’t helpful.
That’s what was wrong with this article. It provides no good introduction or context about what it’s purpose is, and no clear explanation for the relavance of the code it shows. I understood the whole lot, but was left wondering ‘What was the point? What was it trying to say?’. The author surely knows he’s onto something good, but doesn’t communicate it well.
The fact that most people here simply toss out comments telling me that bash is for the prompt and perl is for scripting simply tells me that you have used broken tools for so long that you think they are the norm.
Right, they should graduate to more powerful and feature-rich shells, like command.com
laughable how many so-called gurus do not understand their own OS
bash is not “ls” and “grep” and “cat” these commands i can run from any shell, even the perl shell psh
bash is the syntax that glues them together, and it is horribly broken compared to any modern language, yet your own mental handicaps can’t get past that
think of what you would do with no preconceived notions and no history…would you really separate scripting and interactive shell syntax? i don’t mean commands, as i have already informed you they are shell-agnostic. i mean the syntax.
“laughable how many so-called gurus do not understand their own OS
bash is not “ls” and “grep” and “cat” these commands i can run from any shell, even the perl shell psh
bash is the syntax that glues them together, and it is horribly broken compared to any modern language, yet your own mental handicaps can’t get past that”
Your statements are also laughable. ls is a builtin in bash and so is cat. You are correct that they exist in many shells, and that they exist in /bin (usually) and are thus callable by any program, but they are also part of bash.
Mental handicaps? Name calling is never an answer. Only mentally handicapped people would do that, not that I’m calling you mentally handicapped or anything.
Sorry, brandon, neither “cat” nor “ls” are builtin to bash.
I am curious as to what shell WhoopDeeDoo uses, though.