Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
GNU is Not Unix Programming Unix Linux

Adding Some Spice To *nix Shell Scripts 411

An anonymous reader writes "Developing GUI script-based applications is time-consuming and expensive. Most Unix-based scripts run in a CLI mode or over a secure ssh session. The Unix shells are quite sophisticated programming languages in their own right: they are easy to design and quick to build, but they are not user-friendly in the same way the Unix commands aren't (see the Unix haters books). Both Unix and bash provide features for writing user friendly scripts using various tools to build powerful, interactive, user-friendly scripts that run under the bash shell on Linux or Unix. What tools do you use that spice up your scripts on the Linux or Unix platforms?"
This discussion has been archived. No new comments can be posted.

Adding Some Spice To *nix Shell Scripts

Comments Filter:
  • by TheSunborn ( 68004 ) <.tiller. .at. .daimi.au.dk.> on Monday April 19, 2010 @07:21PM (#31903958)

    None, I have given up bash scripting. The syntax and semantic are simply to wierd. And it can't handle filenames with space in them without some serious hack magic.

    Maybe its time someone (re)-invent a total new shell, with a sane scripting language, commands with consistent names for the same arguments and in general something which don't feel like I live in 1980.

    And I am a fulltime linux used, and a software developer, and I do use the shell as an interactive interface, but I newer script it, and I always have the feeling that I am using a 20 year old interface with so many issues that its insane. Kinda like the same feeling I get when I use sas(The static package. Nice features HORRIBLE interface)

  • Re:None! (Score:2, Interesting)

    by Antidamage ( 1506489 ) * on Monday April 19, 2010 @07:37PM (#31904136) Homepage

    Sometimes you just have too many flags to really want to be hammering things haphazardly into a single line. In that case guided scripts seem like a fine solution, too. Any simple frameworks out there to save reinventing the wheel?

  • Stop using the Shell (Score:5, Interesting)

    by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday April 19, 2010 @07:38PM (#31904158) Homepage Journal
    The shell is a poor clone of 1950's algol. Today, scripting in Ruby or Python yields scripts that can handle errors with advanced facilities like exceptions, and is more maintainable, and can connect to a number of different GUIs or the web.
  • Re:None! (Score:3, Interesting)

    by CAIMLAS ( 41445 ) on Monday April 19, 2010 @08:10PM (#31904486) Homepage

    Often, I find myself writing scripts dealing with tasks which are semi-automated: I need a couple variables of input to deal with variance, but for the most part it's a repetitive task.

    What you're referring to is a batch script; that's good and fine, and I need those two. But that doesn't mean that interaction delineates a "script" from an "application".

    Though, I agree on one thing: a script is a script. There's no need to throw a dialog on there unless it in some way cleans up your input/output code and/or makes parsing the input cleaner.

  • Re:None! (Score:3, Interesting)

    by grcumb ( 781340 ) on Monday April 19, 2010 @08:18PM (#31904552) Homepage Journal

    I know this is troll-ish, but the way I view it a script is just that.. a script. A series of commands to be executed in a specific order designed to automate a repetative task. Basic logic, control, and input are generally ok.. but interaction is in my opinion an indicator that your task is out of scope for a "script" and should become a full fledged application.

    Well, there's interaction and then there's interaction. The grey area between script and application might be larger than your instinct tells you....

    I do document processing for large volumes of legal materials. A number of my scheduled tasks require graduated responses. If the task completes as desired, then no interaction is necessary. If the task encounters one of a set of known issues, then some sort of logic is necessary to decide whether it needs a technical remedy or whether an expert legal editor needs to intervene.

    Because the steps are somewhat malleable (we receive documents from 20 different countries), it makes sense to break the process down into a series of discrete stages. Perfect for scripted solutions. But because interaction with humans might be required at any stage, we also need something a little more receptive to input than a number of command-line parameters.

    My scripts get wrapped into a proper framework that formalises the way in which they're run, their interfaces to syslog and email, as well as allowing custom logic (in the form of callbacks) in parsing STDOUT and STDERR. They're still scripts, but they run in an environment that smells a lot like userland[*].


    [*] Yeah, I know.

  • tcl/tk (Score:3, Interesting)

    by drolli ( 522659 ) on Monday April 19, 2010 @08:19PM (#31904554) Journal

    Honestly it its just about adding a button so that its not necessary to remember the command line arguments/switches, i prefer tcl/tk. Lightweight, portable (and ported), and stable. And if you need a little more functionality, there are tons of libraries available.

  • by walkoff ( 1562019 ) on Monday April 19, 2010 @08:40PM (#31904700)
    There are times when bash/ash/dash... are all that is available or can be made available. Ruby and Python and the myriad other scripting languages are all very good but in memory, cpu and diskspace starved devices shell is the way to go. even the mini-versions of perl and Ruby etc. are a PITA to get working in embedded devices especially if you are using uClibc.
  • by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday April 19, 2010 @08:45PM (#31904734) Homepage Journal

    I like Larry and the rest of the crew, but I think we can confidently say that Ruby is an evolution from Perl. It used to be that CPAN was a big advantage, but ruby gems have come along pretty well since then. And there's a lot to be said for the Rails framework, even more in 3.0 .

  • by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday April 19, 2010 @08:48PM (#31904766) Homepage Journal

    There are times when bash/ash/dash... are all that is available or can be made available

    Because you're running Busybox. Which means it's my fault :-)

    The evolutionary successor of busybox, which I've been thinking about for a while, will not use the shell language. We can raise the bar significantly.

  • by Ajaxamander ( 646536 ) on Monday April 19, 2010 @08:59PM (#31904862) Homepage
    From my understanding, the reason it's called "My Computer" in Windows is to force (lazy) programmers to handle spaces in file paths. But that could just be a rumor.
  • by martin-boundary ( 547041 ) on Monday April 19, 2010 @09:38PM (#31905220)
    Sorry, those advanced facilities are overhyped. How do you (eg) pipe commands together in Ruby, Python or Perl?

    AFAIK(?), none of these languages come close to the simple expressivity of cmd1 | cmd2 | cmd3 > file1.

    The shell's purpose has always been to serve the user. From the perspective of a user, advanced programming facilities like exceptions are not just useless, but can seriously get in the way.

    Programmers write pages and pages of code, and they appreciate class hierarchies, vector operations, etc. Users write throwaway scripts that are run once or twice.

    Programmers like powerful languages that make maintenance easy. Users like powerful shells that make simple interactions really easy.

  • by OA ( 65410 ) on Monday April 19, 2010 @10:49PM (#31905756) Homepage

    I agree python is lots of fun... but I do not call following script to be nontrivial.

    > In Python, you can do things like
    > junk_extension = (".temp", ".tmp", ".junk")
    > if filename.endswith(junk_extension):
    > os.remove(filename)

    Your problem is: thinking ten lines of "if" statements to look at a filename.

    This kind of things are done in 1 liner single shell command. This is too simple to bother python.

    Please read about the "find" command. especially with --exec rm '{}' \;


  • by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday April 19, 2010 @11:41PM (#31906106) Homepage Journal

    One of the early shells - either Steve Bourne's or Ken Thompson's, was written in a set of macros that converted C into an Algol-like language. I was at the NYIT Computer Graphics lab running version 6 Unix on PDP-11, and the funny C was a headache to us systems programmers. Eventually that got cleaned up, later versions of the source probably don't include the macros.

    Working with servers??? I am really far from convinced Bourne shell has any advantage in expressiveness or functionality for that task. For example, even opening a file descriptor and then iterating upon it is awkward in Bourne shell - you end up stowing it as some FD number over 2, and then writing odd redirection like "3>&" on every line that connects with it.

  • by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday April 19, 2010 @11:54PM (#31906178) Homepage Journal

    none of these languages come close to the simple expressivity of cmd1 | cmd2 | cmd3 > file1.

    This is sort of like saying that no language has anything that lets you align text like FILLER PICTURE in old Fortran. Sure, but you don't need to do it. I don't ever have to pipe to sed, because I can do File("foo.txt").read.gsub(/^Foo.*Bar$/, 'Hello!') and get the same result.

  • by Anonymous Coward on Tuesday April 20, 2010 @12:44AM (#31906458)

    That was "Program Files", or "PROGRAM~1", as it was known to the typical Windows 95 era installer script.

  • Re:Pashua on OS X (Score:3, Interesting)

    by iliketrash ( 624051 ) on Tuesday April 20, 2010 @02:09AM (#31906920)

    If you would get your facts straight there would be no need to flame.

    OS X has been UNIX 03 (SuSv3) registered and POSIX compliant since 2007.

    FYI, no version of Linux is registered Unix.

    Read these and learn:
    http://en.wikipedia.org/wiki/UNIX_03 [wikipedia.org]
    http://images.apple.com/macosx/technology/docs/L416017A_UNIX_TB_FF.pdf [apple.com]
    http://www.apple.com/server/macosx/technology/unix.html [apple.com]

  • Re:Pashua on OS X (Score:2, Interesting)

    by iliketrash ( 624051 ) on Tuesday April 20, 2010 @02:16AM (#31906956)

    Oh, where to start. Comparing Aqua to Cocoa is like comparing bananas to cars. Aqua is the name for the GUI components http://en.wikipedia.org/wiki/Aqua_(user_interface) [wikipedia.org] and Cocoa is the preferred API http://en.wikipedia.org/wiki/Cocoa_(API) [wikipedia.org]. Aqua has not been deprecated, not now and not "for years." You can write OS X apps in Aqua using Carbon which _has_ been deprecated for years but is still fully supported. Many popular (and older) OS X programs still run in Carbon such as Quicken, Igor Pro, and at least until recently, Microsoft Office.

  • Blur! (Score:3, Interesting)

    by flajann ( 658201 ) <[ed.xmg] [ta] [llehctim.derf]> on Tuesday April 20, 2010 @03:07AM (#31907142) Homepage Journal
    The line between what is a "script" and what is an "application" has been blurred. Ruby, Python, and PHP are all "scripting languages" and yet many, many killer applications are written in them (like Blender, for example!).

    Bash scripting definitely has everything you'd need to write an "application" in, but many data constructs would be awkward to implement in Bash, so you'd use Python, Perl, or Ruby.

    But what I can do in Bash I could also do in Ruby or Python very easily. What I could do in Ruby or Python would be very difficult to do in Bash.

    Then you have Java and C++ which are clearly not scripting languages, but I could do everything there that I could do in Bash. On the other hand, most things interesting you can do with C++ would be next to impossible with Bash. You just can't beat the performance of compiled languages. On the other hand, development would be costlier and portability might be an issue.

    Then again, you can tap a thumb tack in with a sledge hammer, but you run the risk of putting a nasty hole in your wall!

    It all comes down to what is the right tool for the job. So many tools, though! So pick and choose wisely. But you knew that already.

    Personally, I have given up on making a distinction between what is a "scripting language" and what's an application language. Javascript(!) is a "scripting language", but there is a high level of interactivity in the applications it's used for typically. Both in communicating with the server (AJAX) and with the user.

    Many of these so-called "scripting languages" allows for object-oriented programming. Bash, of course, does not. But then it was never meant for that level of sophistication. But that's even more blur for you. But you knew that already too.

  • Re:Are you serious? (Score:3, Interesting)

    by Bruce Perens ( 3872 ) * <bruce@perens.com> on Tuesday April 20, 2010 @12:05PM (#31911570) Homepage Journal

    I have written some pretty sophisticated shell programs, including one thing for Debian that took a set of executables and a set of shared libraries and made versions of the libraries containing only the functions called for in the executables. It got the system to fit on a floppy when it otherwise would not have. It did a lot of list-processing in shell. Fortunately, someone eventually replaced that with a non-sh program.

    At this point I would not write another large shell script of any kind, and am mostly doing the three-liners in Ruby as well.

    The reason you would learn the shell would be to pass a certification test. You would be a better sysadmin or programmer if your main scripting language was Python or Ruby.

The intelligence of any discussion diminishes with the square of the number of participants. -- Adam Walinsky