User: Password:
|
|
Subscribe / Log in / New account

Shell programming

Shell programming

Posted Dec 7, 2012 22:02 UTC (Fri) by davidescott (guest, #58580)
In reply to: Shell programming by bronson
Parent article: Quotes of the week

> Shell (without bashisms) seems to be as close to eternal as the computer industry can manage.

Not so sure about that. Trying to run a shell script on an older sysv system I think bash-isms are the least of your problems. Consider all the gnu-isms in the commands you use every day.

Compare the single unix specification ls (copyright is only 11 years ago):
http://pubs.opengroup.org/onlinepubs/009695399/utilities/...
to gnu ls:
http://unixhelp.ed.ac.uk/CGI/man-cgi?ls

-A, --author, -b (aka --escape), --block-size, -B (--ignore-backups), --color, -D, --file-type, --format, --full-time, -G, -h, --si, --dereference-command-line-symlink-to-dir, --hide, --indicator-style, -I, -k, -N (--literal), --show-control-chars, -Q, --quoting-style, -R, -S, --sort, --time, --time-style, -T, -U, -v, -w, -X

If you think about POSIX sh as the "core language" and all the programs in /usr/bin as the "libraries" for that language, then shell has seen a very stable core language and a massive expansion in the number and variety of libraries. On the other hand languages like ruby/python/etc have evolved more evenly across the language/library split.

"Shell is universally understood" has more to do with the overwhelming success of the GNU system and the power of open-source to push out the inferior closed source versions. Not that shell programming has been completely static.


(Log in to post comments)

Shell programming

Posted Dec 7, 2012 22:07 UTC (Fri) by dlang (subscriber, #313) [Link]

The key is in backwards compatibility, not in lack of change.

If you take a shell script from 20 years ago, the odds of it being able to run on a system today are very high

Perl is also fairly good about backwards compatibility, but I don't know how far back Perl 5 goes.

most other languages are far worse, and if you take a program written in them 10-15 years ago (if they were even around that long), the odds are very poor that you could run the program today without going through a porting effort that would be comparable to porting to a different language.

Shell programming

Posted Dec 8, 2012 1:35 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

HAhahahahadhahadkLOLOLL.

I've recently spent 5 hours rewriting old scripts from a long ago retired Sun box. Searching old manuals to understand what non-standard command line options do is such a great way to spend time. Especially when it's not possible to simply run them.

Shell programming

Posted Dec 8, 2012 2:05 UTC (Sat) by sitaram (guest, #5959) [Link]

That has nothing to do with shell per se. It's just non-open source versus open source. If they were open source you'd still be able to compile and run them.

As for non-standard options, I suspect most of the Sun utilities would be closer to BSD.

Shell programming

Posted Dec 8, 2012 2:11 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Even if they were OpenSource (which they are), you'd need to compile 20-year old crufty C code and quite likely newer GCC versions won't do the trick. Waaaaay too much work.

On the other hand, I've ported 15-year old Python scripts without much problems. There were several non-backward-compatible changes in Python since then, but they are fairly minor.

Shell programming

Posted Dec 8, 2012 6:53 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Some anecdara:

For Python, one I hit today was to change "except BaseException as e:" to "except BaseException: e = sys.exc_info()[0]" to support 2.4 through 3.2 in the same script. A little annoying, but not as pretty as either just-one-way canonical syntax.

As for shell, we found out that BSD sed and GNU sed don't support compatible -i flags. BSD requires a suffix, GNU requires there be no space if one is given, which BSD rejects. Using manual .bak files feels worse than either by a long shot. I think the call has been replaced by awk instead now.

In my experience, GNUisms tend to be harder to work around than Python incompatibilities. That's why I try to avoid them in my shell scripts. Unfortunately, sed -i is very convenient and sponge just isn't common enough, but this is slowly being trained out of my fingers when I'm in "portable" mode (I use every trick I can at the prompt, just not when writing .sh files).

Commands on an old Sun box

Posted Dec 10, 2012 7:19 UTC (Mon) by jrn (subscriber, #64214) [Link]

Have you looked at the heirloom toolset (http://heirloom.sourceforge.net/)?

Commands on an old Sun box

Posted Dec 10, 2012 14:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope (I didn't know about it).

In any case, I was interested in a rewrite in a sane language, not just running these scripts.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds