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?"
Pashua on OS X (Score:3, Informative)
On OS X, I use Pashua, http://www.bluem.net/en/mac/pashua/ [bluem.net]. This is a brilliantly simple thing to use. I also use it for other (non-script) languages for making a quick-and-dirty GUI that still looks nice and is a real Cocoa program.
Re: (Score:3, Interesting)
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: (Score:3, Funny)
FYI, no version of Linux is registered Unix.
Thank God for that!
None! (Score:5, Insightful)
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.
(you may now freely argue amongst yourselves on the difference between a script and an application)
There are a metric ass-tonne of dialog-type apps out there .. just google for your favorite toolkits prefix and "dialog" and you'll probably find something..
gdialog
kdialog
xdialog
etc..
Re: (Score:2)
Re: (Score:3, Interesting)
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
Re: (Score:3, Interesting)
Well, there's interaction and then there's interaction. The grey area between script and application might be larger than your instinct tells you.
"Interaction" (Score:5, Informative)
Of course, this all starts to break down with GUIs.
Blur! (Score:3, Interesting)
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 Pyt
Re: (Score:2, Interesting)
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?
Just Bash? (Score:3)
Limiting yourself much? Also *nix != bash and bash != *nix though I imagine all shells share a host of similar commands.
Re: (Score:2)
It's not just the built ins it's how they're used, you don't want to be caught scripting in
the usuals.... (Score:2)
sed, awk, grep, strings, lots of pipes, and randomly useful scripts made from them stuffed into my ~/bin folder...
Re: (Score:2)
Re: (Score:2)
If you know that your user has a GUI, there's zenity [wikipedia.org] which you can use to send a GUI message box to your user with.
None, I have given up bash scripting (Score:2, Interesting)
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
Re: (Score:2, Funny)
it can't handle filenames with space in them without some serious hack magic.
Use quotes
Re: (Score:3, Funny)
That's what novice "experts" usually say to do. Then you end up getting filenames that contain quotes. So what started as just escaping spaces turns into escaping spaces and two types of quotes. Depending on the approach you use here, you may need to escape some other characters, just in order to escape quotes, just so you can escape spaces, just so you can deal with filenames containing spaces.
Any sensible person would say "fuck it" and just use a real scripting language like Python, Ruby or Perl.
Re: (Score:2)
Bash's strength lies not in it's awkward syntax and idiosyncrasies, it lies in the ease with which bash passes arguments to other programs and grabs the return values. In a few lines bash can call precisely the tools needed and string together some very powerful tools. Sure, similar things exist in python and can be accessed easily. but you can't eek out the same flexibility or succinctness as you can with bash for many tasks.
Unsurprisingly, the place where the *nix collection of tools shines in text manipu
Re: (Score:3, Insightful)
Ummm... yeah. Try "tar tf file.tar | xargs rm", when some of the files in the archive contain spaces (or other shell special characters).
Re:None, I have given up bash scripting (Score:5, Informative)
Use:
That will work unless the filenames contain newlines in them.
Re: (Score:2)
Doggone it! You'd think, after 25 years of Unix, I'd know about that option. That's a good one. Thanks.
I guess I'll have to read the man pages a little more often.
Re: (Score:2)
I think that just illustrate the point that Bash have nice features but horrible syntax and magic.
Re: (Score:3, Informative)
Use:
That will work unless the filenames contain nulls in them. They won't.
Re: (Score:2)
tar tf file.tar | while read file; do rm "$file"; done
This works because the entire line is read into $file, spaces and all.
Handling spaces (Score:2)
Ummm... yeah. Try "tar tf file.tar | xargs rm", when some of the files in the archive contain spaces (or other shell special characters).
In your example, I'd use a read loop to treat each line of of output as a single element. Handle each line using double quotes.
In most cases, an array works fine for preserving special characters in file-names.
mkdir /tmp/test /tmp/test
cd
touch 'foo'
touch 'bar baz'
declare -a FOO
FOO=(*)
Foo now contains an array. Each element is a single file-name, that preserves shell special characters.
Foo has 2 elements
$ echo ${#FOO[@]}
2
Those elements are:
$ for ELEMENT in "${FOO[@]}"; do echo $ELEMENT; done
foo
bar baz
Elements
Re: (Score:2)
I knew you could handle files that way, but I didn't know it preserved special characters.
One thing I will say: bash is generally better about this than ksh, on real Unix systems. If I remember correctly, something like "for file in *" in bash will ignore special characters and run the loop once, for each actual file. Ksh, on the other hand, will pay attention to special characters.
Re: (Score:3, Informative)
something like "for file in *" in bash will ignore special characters and run the loop once, for each actual file.
bash's for loop understands * as a special case. if you need something like "for file in $(find ...);" you'll get one loop per word again. Also, even when you get one loop per file, you still have to quote $file when you use it because bash parses arguments to the command after variable substitution, so something like touch $file when $file is foo bar becomes touch foo bar where foo and bar ar
Re:None, I have given up bash scripting (Score:5, Informative)
Does `find . -print0 | xargs -0` really qualify as "serious hack magic"?
Re: (Score:2)
What's the problem with File\ Name.txt?
Re: (Score:2)
The problems occur when you start writing scripts, and start passing filenames around in pipes and whatnot. Generally speaking there are ways to avoid doing that, but it's not uncommon to realize that you accidental put yourself in that sort of a situation.
Re: (Score:3, Informative)
Some command languages handle ok (ie, DCL, DOS) because t
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Use emacs. It's the best of all worlds...
Well... (Score:3, Funny)
I would, don't get me wrong. Emacs is a lovely operating system. I just wish it had a decent text editor.
Re:None, I have given up bash scripting (Score:5, Insightful)
You mean something like perl? Or maybe python?
My vote is for perl. It's more common in a "base install" than any other shell (in the BSDs and most Linux distros) and has a non-trivial amount of power. It's good at dealing with path and input permutations and you can interface it with pretty much anything. Hell, pcre came from perl, and that's used almost everywhere these days: it's got a lot of things right for the little that's wrong, at least in terms of being a good scripting language.
I avoid "shell" scripting (csh, sh, bash) if at all possible, too. The contortions necessary to do the frequently-necessary evaluations takes quite a bit longer, even with a chain of awk/sed/grep and the like. Unlike those languages, perl is entirely self-contained and does not have any system-specific oddities (eg. with a shell script, many system binaries are different and an option/parameter pair on one system might do something entirely different on another - or not work at all).
I realize perl can often (usually) be difficult to read. But for my purposes, it's good enough, because I'm a bit of a prolific comment writer as a matter of process.
Re:None, I have given up bash scripting (Score:4, Insightful)
It doesn't have to be that way. I always try and write Perl to be readable rather than concise. Sure I might take 6 lines to do something that can be done in 1 and may use some other stuff that isn't particularly necessary but I'm writing to get the job done and for maintenance, not to show how clever I am.
Re: (Score:2)
Re:None, I have given up bash scripting (Score:5, Insightful)
Simple solution: don't use filenames with spaces in them. They're an incredibly stupid idea. If you need something that looks like a space, use an underscore. The same practice has been done in C since the early 70s, since having spaces inside C tokens would be stupid.
Simpler solution. Don't use computers.
Seriously now. You expect all the end users out in the world to stop using spaces... just so your script works?
Re: (Score:2, Insightful)
Re: (Score:2)
As I said before, I already provided a solution: error out when encountering broken filenames like this. A two-line test is all that's needed. There is absolutely no good reason to have a space in a filename.
That bon mot is little help when you have to deal with filenames that contain spaces.
Enabling bad practices only allows these practices to continue, just like enabling freeloaders by giving them what they want will only cause them to continue freeloading instead of getting a job.
The "fsck 'em -- just error out" and " Go away -- you're stupid" mindset is part of what gives UNIX a bad name in general. UNIX is not free of horrible programming practices; no OS is. And there have been some awkward choices in the past 40 years.
Until all that stuff is fixed, you might want to STFU unless you want to grab the source code and fix it. And if you wrote it . . .
Re: (Score:2)
> No, I expect competent programmers to not do incredibly stupid things, like use filenames with spaces in them.
It is really difficult to find programs that create file names with spaces on purpose.
The problem is that computers are used by..... people! and you know, people is used to spaces to separate words, so the file names will also carry that hideous defect.
Re: (Score:2)
So you expect computers only to be used by competent programmers? In my world there's about 1 competent programmer to every 5000 or so regular users. You've got to expect spaces in your filenames.
Re:None, I have given up bash scripting (Score:5, Insightful)
Re: (Score:2)
It's 2010. We have all kinds of advanced, powerful software, and a space is a perfectly valid filename character (unlike the C tokens you mention, where they are not actually allowed).
No, while it may be technically valid, it's no more a good practice than embedding various high-ASCII characters (like #s 179-223) in your filenames. It just makes it extremely difficult for people to retype those things.
Most unicode characters are not used as field delimiters. Spaces are. That's the reason they shouldn't b
Re: (Score:3, Insightful)
(try opening a DOS shell on XP and typing in a command using a filename with spaces, without quotes).
Yah! Now try typing a command without using the letter 'R' or 'C'!!
Oh wait, you're introducing a ridiculous handicap to demonstrate your retarded point. Turns out, here in the real world, keyboards actually *do* have a key for typing quotes-- so it doesn't fucking matter if the command requires quotes.
Look, regardless of your "special" way of naming files, the point is that *other people* who don't share you
Re: (Score:2)
Gtk2-Perl (Score:2)
I really can't praise Gtk2-Perl enough. Using Glade to quickly build your GUI, and Perl to quickly build your logic, it's a knock-out combination. The end result looks just like a gnome application ( using Gtk2 ), and for 95% of cases, runs as fast as well. I liked it so much, I wrote some database classes, Gtk2::Ex::DBI and Gtk2::Ex::Datasheet::DBI ... see: http://entropy.homelinux.org/axis/ [homelinux.org].
Re: (Score:2)
I really can't praise Gtk2-Perl enough. Using Glade to quickly build your GUI, and Perl to quickly build your logic, it's a knock-out combination.
Heh, I'll see your GUI and raise you transparency. I've got a little dashboard applet that uses X11::Aosd to display a translucent status display for all my key servers. Yes, I know I just re-invented Conky, but because it's Perl I can use SSH::RPC in the back end to securely talk to my servers in order to get quick and dirty performance metrics.
One of the things scripting does well is to chop tasks into small, manageable steps. While system monitoring is a complex and demanding process, all I really need o
It's pricey but.... (Score:3, Funny)
One day.... one day....
Re: (Score:2)
Off the top of my head... (Score:5, Informative)
I work as a Linux netadmin and system developer, so I do a lot of shell programming in (ba)sh. Here's some of the niftier things you can do to a shell script:
- Make colored output with shell escape sequences. Works especially well with red type for error messages, makes them really stand out.
- Use inline functions a lot. The great thing about them is that you can pipe to them and use them in all kinds of places. For instance, to do mysql queries:
mysql_query() { /usr/bin/mysql --user=root --pass=topsecret database
}
echo 'SELECT * FROM accounts' | mysql_query
- "Here documents". For long MySQL sequences, something like the following (reusing the mysql_query function from above):
cat - EOF | mysql_query ...
SELECT bar
FROM foo
WHERE baz
EOF
This lets you easily format stdin for scripts and other programs. Also really useful for outputting HTML and stuff like that. Best thing is that variables are expanded inside the block.
- The || and && operators. Check if a file exists, remove if so, else complain: /tmp/somefile.txt ] && rm /tmp/somefile.txt || echo "Does not exist!"
[ -f
Also common in this form: /usr/bin/necessaryprogram ] || { echo "aaargh"; exit 1; }
[ -x
- Making a "multithreaded" shellscript is also one of my favourites. Say, you want to start five virtual machines at the same time. Write a function that starts a vm, and call it a few times in a loop, backgrounding each instance with &, and saving their PIDs. Then have a "wait loop" that waits for the PIDs to exit the system (or for a timeout to occur).
- Proper argument handling with getopt. Have your script take "real" arguments in any order, just like real binaries.
This just scrapes the surface of the surface, of course. I learn new stuff every day.
Nice example. (Score:2)
I do a fair bit of shell scripting, but your script-fu is better than mine. I've just printed your sample go over again later with my copy of Ken Burch's book in hand to make sure I understand every nuance. I don't think I've EVERY printed anything from /. before.
Re:Nice example. (Score:4, Informative)
Thanks, it's nothing I couldn't show a fella. Learnt a lot from my colleagues and from the O'Reilly 'Unix Power Tools' book. The Advanced Bash Shell-scripting Guide is pretty good (but chaotic) too.
The syntax filter here munged some of the examples, though. The here document example will not work as-is, because there should be two 'less-than' signs in front of the minus sign. The mysql_query function probably also won't work (can't bother to run a test), because the newline after the first bracket mysteriously disappeared. So best to loop up the concepts in some kind of reference manual.
Re: (Score:2)
Thanks, it's nothing I couldn't show a fella. Learnt a lot from my colleagues and from the O'Reilly 'Unix Power Tools' book. The Advanced Bash Shell-scripting Guide is pretty good (but chaotic) too.
Wow. Great attitude. I hope Mr. Just-Error-Out reads your posts.
Since I live in my parent's basement... (Score:3, Funny)
I use the usual: sed, [, wget, etc to automate downloads of pr0n.
You mean that VI (Score:2)
is not a GUI?
Re: (Score:2)
More of a TUI [wikipedia.org] if you want to be pedantic.
I dissent (Score:2, Insightful)
Re: (Score:2)
I'm inclined to agree, given that I've written several dynamic web pages in shell.
Re:I dissent (Score:4, Insightful)
It implies that the script will only be run by human users (and probably, human users who happen to run a particular flavour of GUI). Traditional shell scripts are written for all users, not just human users.
Why should developers care about non-human users? It's what makes automation possible. Every time time a script delegates work to another script, that's a non-human user scenario.
If you build enough scripts that can be used by all users, then you have a critical mass and your system becomes really powerful. If you build enough scripts that can only be used by human users, then your system stays weak, for it is limited by the actions of a single human operator.
Stop using the Shell (Score:5, Interesting)
Re: (Score:2)
The shell is a poor clone of 1950's algol. Today, scripting in Ruby or Python...
It was a great day when I decided no more bash scripts, ever. Ruby is so much nicer...
Re: (Score:2, Interesting)
Re:Stop using the Shell (Score:5, Interesting)
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.
Re:Stop using the Shell (Score:4, Interesting)
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.
Re:Stop using the Shell (Score:4, Interesting)
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.
Re:Stop using the Shell (Score:5, Insightful)
Sure you can get the same result, but the syntactic sugar in your example is much more verbose, and conceptually more complex.
For each of the three components, there's a mental context switch (File object on the left, reader object in the middle, and substitution method on the right).
The shell language does the right thing by handling components more uniformly (ie they all have STDIN/STDOUT regardless of the nature of the command). The user needs to know what each command will do, but he does not need to know if the result is an array object, or a stream ojbect, or a file object etc.
The shell also has less redundancy. Compare cat foo.txt with File("foo.txt"), there should be no need for both parentheses and quotes. Now in the wider scheme of Ruby this redundancy makes perfect sense, but users don't need all this, only programmers do.
Users need the bare minimum to communicate with the machine in a language that takes 30 seconds or less to type (or speak in a microphone...), but still lets them do as much as possible.
It's an interface issue, it's got little to do with the range of things that can be done in the language. Ruby is much more powerful than bash, but bash is still better at starting and stopping programs (and rc is better than bash...).
And use Python or Ruby instead? Not so easy (Score:4, Insightful)
I use sh and relatives (and vi) because they're ubiquitous, stable, small, light, and reasonably fast, consistent, capable, and fairly understandable. Every program in /etc is a shell script, and by default system utilities such as cron call on sh. Everything entered at a command line is interpreted by sh. sh is as much a part of UNIX systems as C. You might as well suggest GNU/Linux be rewritten in a better language than C.
And if you're going to suggest that, why not also reexamine the basic architecture of UNIX? If anyone produces an open, formally verified microkernel OS in Haskell that actually works, isn't dog slow, and has sufficient functionality and apps to be useful, I'll surely check it out. I'd love to see more consistency between how applications accept parameters from the command line and how programming languages handle parameters. The former tends to be named and unordered, while the latter is anonymous and ordered. Then there's the defacto standard for libraries, worked out in the days when memory and disk space was extremely limited. It doesn't support enough meta information, making it necessary for a compiler to read header files. It's made libraries many little worlds of their own. As long as a programmer sticks to C/C++, it is relatively easy to call C library functions, but step outside that and it becomes a huge pain. Therefore we have these monstrous collections of duplicate functionality and wrapper code such as CPAN, abominations such as SWIG, attempts to bridge things by providing some commonality and standardization such as CORBA, and separate worlds such as the gigantic collection of Java libraries.
Something like Perl or Java is heavy enough to be impractical on a slow computer with little RAM. Can take over 5 seconds just to load the language. I'm not familiar enough with Python or Ruby to know if they're as heavy. You can't always be sure they're there, whereas whatever was used in /etc/rc.d, and is run in a terminal, is guaranteed to be present. Don't know about a "pysh", but there is a "perlsh", for use in a terminal. Never seen perlsh used though, and it seems to demand a nasty hackish sort of interaction. Press Enter twice to execute commands, as one press of Enter is apparently used as a statement or formatting break. Maybe that's because those languages actually aren't too suitable for an interactive environment? As to connecting to the web, there's wget, wput, and curl.
It could be a lot worse. Bash is pretty nice compared to MS DOS batch language.
Re:Stop using the Shell (Score:4, Interesting)
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 .
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
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
Re: (Score:3, Insightful)
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.
The problem is that in most half decent language you can express almost anything. It is about choosing to refrain from expressing. As I stated, to me shell scripting languages are mostly about setting up environments and starting shells.
I've seen people creating monstrous programs in Bash -because apparently the f...ing could- using complex arrays, reinventing clib functions, resulting in an badly performing system, rendering their product unmanageable and thus becoming a liability.
I program only since
Re: (Score:3, Informative)
I haven't looked at how Rails 1.9 garbage-collects a thread, but it doesn't look as if you have to join it to make it go away. 1.8 did not use OS threads, but just switched tasks when I/O blocked.
Re: (Score:3, Interesting)
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
3D goggles! (Score:3, Funny)
Combined with red and blue text the goggles make my facepalm ASCII art really pop!
You see, I use ASCII art in lieu of the dialog boxes for user feedback. It's more intuitive to show facepalm guy when I ask the user for a digit & they give me a letter. They understand right away that they're an idiot.
Why (Score:5, Insightful)
The CLI is powerful because it's a CLI, you do not need or want pretty dialog boxes. Help is whats available with man --help usefull errors messages and the contents of /var/log. It works over 9600 baud serial and works pretty well so you can ssh from your smartphone with 1 bar and fix something at 3am before the GUI would have time to come up to a login screen. A good CLI expects things to be piped into and out of it and can get any required information via the command line. The power of the CLI is that you can chain bits together run to do things or wrap scripts around other scripts and do useful work.
You point to a 20 year old book that mostly bitches about how slow/ugly X is, guess what things have come a long way, I run one laptop with native X and it looks good is responsive I export X all the time over ssh to my primary desktops. Take a step back and think why your trying to shoehorn GUI functions onto a CLI if you really need to do it look at some of the toolkits that can detect if there is a X server present and use that fallback to text gui and run entirely headless by pure command line but think long and hard about why you would want to do this.
tools I found useful (Score:5, Informative)
Here are some random things I find useful, related to user interaction (mostly becuase it notifies the user):
Oven timer:
sleep $((20*60)); xmessage "Dinner is done"
Quick macro for automating some repetitive task in a program:
xdotool type "something"; xdotool key Return; xdotool mousemove $x $y; xdotool click 1; (and so on)
Copying a file to/from the clipboard (can also copy from /topipe, so the output of any command). Faster than opening a text editor:
xclip -in file
Notifying me when some specific thing changed on a website:
CHECKLINE="$(curl -s http://somewebsite.org/somepage.html [somewebsite.org] | grep "currently undergoing maintenence")"
while true; do
sleep 120
[ -z "$CHECKLINE" ] && xmessage "somewebsite is open again" && exit
done
Or just checking for changes in general (I use this for notifying me when something changed when tracking something I ordered, so I know the minute the package is ready to get picked up at the post office):
while true; do
OLD_MD5=${MD5}
CONTENT=$(elinks -dump 1 -dump-charset iso-8859-1 "http://someurl.com/track?id=someid")
MD5=$(echo -n $CONTENT | md5sum -)
[ "${MD5}" != "${OLD_MD5}" ] && { :\n\n${CONTENT}")"
xmessage "$(printf "New action:
}
sleep 120
done
If you don't want to interrupt what you're doing with a pop-up you can pipe it to osd_cat instead to have the text appear over whatever program you're currently working with. Adding a few beep; beep; beep; beep; is also a good way to get your attention if you're not paying 100% attention to your computer all the time.
Best book for this -- hands down. (Score:5, Informative)
Linux Shell Scripting with Bash
by Ken O. Burtch
Sams Publishing
One of only two "computer" books I've ever been able to just sit down and read rather than just using as reference (the other being Kathy Sierra's "Head First Java" -- which is amazing).
Ken does a fantastic job at putting "just the right" level of background, detail, context, and and depth for someone new to shell scripting to get started, then to use the book as a reference for all the traditional tools (sed, awk, etc..).
I've bought two copies, one for me and one I gave to someone else who wanted to learn how to do this stuff.
Re:Best book for this -- hands down. (Score:5, Informative)
http://tldp.org/guides.html [tldp.org]
free as in beer.
Visual Basic (Score:2, Funny)
I know this is like cursing in the church, but I use VB for most tasks others would use shell scripts for. Why? For one, the syntax is more predictable. With Bash you always have to worry about special characters and I can't stand that. (Same reason I dislike Tex.) Secondly, if you need user interaction, it has a really easy to use GUI builder. When VB4 came out it was like 1995 or something. It is now 2010 and in my opinion, for building simple dialogues (or even not so simple ones) VB is still among the b
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Perl.... (Score:2)
Groovy (Score:2)
def image = Toolkit.defaultToolkit.getImage("some_image.png")
def trayIcon = new TrayIcon(image,"Script")
SystemTray.systemTray.add(trayIcon)
trayIcon.displayMessage("Script Completed", "", TrayIcon.MessageType.INFO)
What do you mean ... (Score:2)
tcl/tk (Score:3, Interesting)
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.
layers of complication (Score:2)
I think you should e-mail that guy that wanted to manage his Windows desktops by running Windows images on top of Linux, using some virtualization technology, but also passing through the hardware capabilities of the video cards, so he could run multiple monitors.
I bet he'd have some great tips about how to spice up your shell scripts. He probably edits them in emacs (running inside an AJAX terminal inside his web browser, connected to a web server on the machine he's editing the file on).
ksh (Score:2, Informative)
KSH just gets a b
Unix doesn't *mind* being ugly (Score:2)
Nice little gem here though.
http://www.linuxfocus.org/English/May2004/article335.shtml [linuxfocus.org]
Be warned though - unix *likes* being ugly. non-ansi terminals quickly fill with garbage when ansi escape codes are printed to them. The same problem is with using purty' X dialog shells. If you don't have the terminal support, or X session, or X libraries installed, your script becomes useless in a hurry.
What tools? (Score:2)
> What tools do you use that spice up your scripts on the Linux or Unix platforms?
sh -x
Consistency is the only spice ... (Score:5, Insightful)
o output errors to STDERR; normal output to STDOUT
o include (-h, --help) processing - and send it to STDOUT so the help can be piped to 'less'
o use getopt(1) or process-getopt(1) so that options on the CLI parse in a predictable and standard way
o keep it terse except for errors so that the user can easily see if it worked or not without scanning vast output
o provide a --verbose option to help with tracking down those errors
Head over to http://mywiki.wooledge.org/BashFAQ [wooledge.org] for much wisdom on how to write better bash scripts.
Combinations of stuff (Score:2)
I'm not really sure what the point of this item is, but I'll be more than happy to blather on about console stuff I like :P
Midnight Commander: (mc) - Mostly I write scripts to make things easier for other people. But there isn't always a good GUI to allow the user to see what scrips are available. So I'll get all my scripts together in a directory and open the directory in midnight commander. Then they can see a sorted list of all the available commands. Gnome panel buttons work OK for this as well, bu
I only write trivial shell scripts (Score:4, Insightful)
I will quickly write a shell script any time I have some simple task I want to automate. You cannot beat the convenience:
/some/directory/$1
cd
some_program --foo $2 --bar $3
rm -f *.temp
Wow, three lines, and it runs the program, then cleans up the temp files that program always litters in my directory. And I don't have to memorize the --foo and --bar options! Shell scripts rock!
The problem comes when you start to do nontrivial things. When you start processing lists of files, and the files can contain spaces, the amount of quoting drives me insane. At that point I rewrite in Python.
The spaces-in-file-names problem can bite even this trivial shell script! If any of the three arguments ($1, $2, $3) is specified as a string containing spaces, this script won't work, because the shell interpreter needs quotes at every step where it evaluates something. If you pass "my file.txt" as the second argument, the $2 won't evaluate to "my file.txt" in quotes, it just evaluates to the bare string. So to be fully safe, the above program needs to be:
/some/directory/"$1"
cd
some_program --foo "$2" --bar "$3"
rm -f *.temp
And woe is you if you forget the quotes.
Python loses in convenience for running a program... here's a Python equivalent of the above:
import os
import subprocess as sp
import sys
os.chdir("/some/directory/%s" % sys.argv[1])
lst_args = ["some_program", "--foo", sys.argv[2], "--bar", sys.argv[3]]
sp.check_call(lst_args)
lst_args = ["rm", "-f", "*.temp"]
sp.check_call(lst_args, shell=True) # run in a shell to get wildcard expansion
At first glance this looks horrible. It's much more than the three terse lines of the original. But it's easier to get right, and this is safer to run. If the user specifies something silly for the first arg, or doesn't provide it, this program will immediately stop after trying to change directories. The original would change to "/some/directory" and blindly run on, trying to run "some_program" there, and who knows what would happen? Likewise, if "some_program" fails, this script will stop immediately, and the deleting of the *.temp files will not occur (making it easier to debug what's going on). Finally, in this code we don't have to worry about quoting the arguments; we can just use the arguments and it just works. It is much harder to write a fail-safe shell script: you would have to explicitly test that $1 is provided, and you would have to check the result of running "some_program" to see if it failed or not.
The nontrivial scripts I write tend to have a lot of logic in the scripts themselves, and Python is much much more pleasant and effective for evaluating the logic. If I want to write a script that sweeps through a bunch of directories and deletes files that match certain criteria, it is so much easier to write the tests on the file in Python. If I write ten lines of "if" statements to look at a filename, that is ten lines where I didn't need to fuss with the double quotes. In Python, you can do things like
junk_extension = (".temp", ".tmp", ".junk")
if filename.endswith(junk_extension):
os.remove(filename)
Shell scripting cannot match this convenience. And note that if I use the native Python os.remove() I don't need to worry about quoting the filename; it can have spaces in it and os.remove() doesn't care.
Other people might prefer to use Perl or Ruby. Either of those, or Python, are much better than shell scripts for anything nontrivial.
steveha
Re:I only write trivial shell scripts (Score:4, Interesting)
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 '{}' \;
Osamu
Re: (Score:3, Insightful)
I do not call following script to be nontrivial.
I don't think I said it was nontrivial; I just said that Python was more convenient. If you wanted to test a single file and see whether it ended with one of three extensions in a shell script, what would you do?
You could do it this way, but it's painful and ugly:
# shell variable "filename" holds the filename
if [ "${filename#*.}" = "temp" ] || [ "${filename#*.}" = "tmp" ] || [ "${filename#*.}" = "junk" ]; then
echo "$filename"
fi
Don
Re: (Score:2)
If you are writing something to be run by end users or have some other reason to need it to look friendly, a) train the end user or b) use something else as a front end to your scripts.
Or just don't use shell scripts at all. Use the best tool for the job. For system administration tasks, shell scripting usually works well. For more complex stuff, Perl is probably a better choice. For something that needs to look friendly and be run by nontechnical users, write it in Python or some other language. You c
I was going to suggest this too. (Score:2)
Zenity is fun, and seems to be offered by default on many distros now.
Basically its a shell front end to the gtk widgets .
Re: (Score:2)
GUI's only help for what some developer has decided should be pre-ordained as possible.
The whole point of scripting is that it has a much lower barrier to entry than coding to some "modern" GUI.
Scripting isn't "elitist", it is infact POPULIST. It is putting computing tools in the hands of more people with less effort and overhead.
It's like Commie Basic.
People that call scripting and text based interfaces "elitist" are like Republicans.