| |||||||||||||
Shell programmingShell programmingPosted Dec 7, 2012 9:03 UTC (Fri) by man_ls (subscriber, #15091)In reply to: Shell programming by sitaram Parent article: Quotes of the week Compactness and the use of pipes: two basic Unix principles. By the way, it appears that the most common last digit in primes is a bit random: running your script for 100 yields 3, for 1000 yields 7 and for 10000 it is 3 again, and for 100000 7 once more. Not bad for a Bash one-liner; and it is not so slow after all.
(Log in to post comments)
Shell programming Posted Dec 7, 2012 10:53 UTC (Fri) by egk (subscriber, #50799) [Link]
Off topic, but anyone interested in the last digit of primes should search for "Chebychev bias", and especially the paper of Rubinstein and Sarnak on this topic. Very short summary: it's much more complicated than one might think...
And if you want to do numerical experiments on this type of questions, the right tool for the job is not a shell-scripting language. (Hint: Pari/GP).
Shell programming Posted Dec 7, 2012 11:35 UTC (Fri) by man_ls (subscriber, #15091) [Link] What is really surprising is that for a quick check, Bash can be useful even for interesting mathematical questions.
Shell programming Posted Dec 7, 2012 12:01 UTC (Fri) by renox (subscriber, #23785) [Link]
> Compactness and the use of pipes: two basic Unix principles.
Maybe but even if I know better the shell than Ruby, the Ruby solution is more readable than the shell one..
Shell programming Posted Dec 7, 2012 19:55 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
for you Ruby is the right answer, for now.
However, how much will Ruby change over time. If new people are hired (or your company is bought out, or you leave and go somewhere else), are these other people also going to be in the situation where Ruby is more familiar to them than shell?
Shell is everywhere. It's hard to administer a *nix system without dealing with shell (you can be an application programmer without dealing with shell, but not a sysadmin)
along similar lines, it's hard to be a sysadmin and completely ignore vi, you may prefer emacs, but any system you touch is going to have vi, not all systems will have emacs.
not all systems will have Ruby, Python, or Perl but every system will have shell of some sort.
Shell programming Posted Dec 7, 2012 20:22 UTC (Fri) by bronson (subscriber, #4806) [Link]
Exactly right. Ten years ago Perl was the answer. Not anymore. (Perl5 is becoming nonessential a lot faster than I thought it would. It's almost scary...)
Scripting languages come and go, and the modern one break their own scripts every five years. Shell (without bashisms) seems to be as close to eternal as the computer industry can manage.
Use the right tool for the job.
Shell programming Posted Dec 7, 2012 22:02 UTC (Fri) by davidescott (guest, #58580) [Link]
> 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):
-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.
Shell programming Posted Dec 7, 2012 22:07 UTC (Fri) by dlang (✭ supporter ✭, #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 (subscriber, #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.
|
|||||||||||||