Boy, is the shell powerful. Post: 302803653

Sponsored Content

The Lounge What is on Your Mind? Boy, is the shell powerful. Post 302803653 by bakunin on Tuesday 7th of May 2013 07:18:17 AM

05-07-2013

Registered User

Quote:

Originally Posted by wisecracker

With so many transient and resident commands at one's disposal is there anything,
non-GUI, that cannot be done inside a default shell and terminal?

Yes and no: from a theoretical point of view the shell language is Turing-complete, so in principle there is nothing you couldn't do given enough resources.

From a practical standpoint, these resources are limited and the theoretical possibility to do something doesn't imply it is also wise to do so. High-level-languages, like Corona already noted, do not have to offer more possibilities, it is enough that they are usually better (faster, smaller, ...) in doing it which makes them preferable for some tasks. They generally also afford more effort to do something (a script in shell is usually written faster than the same as a C program because the "building blocks" are bigger), which makes the shell languages on turn preferable for some other tasks.

Quote:

Originally Posted by wisecracker

I found this type of limitation using RANDOM which is why I switched to /dev/urandom instead.

This might or might not be a good idea. "/dev/random" is the front-end of a driver, which collects noise from device drivers (and some other next-to-random events, implementations vary) to fill a pool of "randomness" (called the "entropy pool"), which can be accessed (via "/dev/random") as source for random numbers of high quality. As this pool is accessed i is depleted and once it runs empty read-access is blocked as long as it takes to refill this pool.

So, yes, "/dev/random" might be slow, but it delivers constant high quality. "/dev/urandom", on the other hand, works similar, but the random numbers are generated by a pseudo-random-number generator. The device will not block like "/dev/random", but once you exhaust the entropy pool you get random numbers of considerable lower quality than from "/dev/random".

So, both these devices have their uses, you will have to decide which one is sufficient for your work. For high-quality cryptography probably "/dev/urandom" won't suffice, while as source for the dice in a game program it might be perfectly OK.

I hope this helps.

bakunin

PS: The Amiga had a very powerful script language itself: (A)REXX. It serves the same purpose on IBM mainframes the shell serves on Unix systems. You might want to give it a try.

Last edited by bakunin; 05-07-2013 at 08:24 AM..

bakunin

View Public Profile for bakunin

Find all posts by bakunin

3 More Discussions You Might Find Interesting

1. OS X (Apple)

Is Mac OS X Server Really Powerful?

Look We all know that Linux is almost BulletProof and about 40% faster than Win2K3 Server, When running Oracle DB, Right? Now my Question is can OS X run just as Well as Linux as a Server being PowerPC and Whatever, Can it be just as stable? Now You Tell me, Which is most Practical: Linux...

2. Shell Programming and Scripting

Any way to make scp more powerful?

Hello, I'm writing a script to automate the delivery of our code to different target environments and I was wondering if there's any way to cut down on the number of authentications that are needed. The script has to deliver to three different boxes (two directories on two boxes and one...

3. Solaris

dd - imaging drives. Oh boy!

Hello, Yes, it's me again. Running around getting this done! My current problem is I'm trying to image one drive 0 (/dev/dsk/c1t0d0s0) to drive 1 (/dev/dsk/c1t1d0s0). I know that drive1 came out of a Sun Server and it is a Sun drive. Solaris 10 recognized drive1 after the devfsadm command. The...

LEARN ABOUT OSX

random

RANDOM(4)						   BSD Kernel Interfaces Manual 						 RANDOM(4)

NAME

     random , urandom -- random data source devices.

SYNOPSIS

     pseudo-device random

DESCRIPTION

     The random device produces uniformly distributed random byte values of potentially high quality.

     To obtain random bytes, open /dev/random for reading and read from it.

     To add entropy to the random generation system, open /dev/random for writing and write data that you believe to be somehow random.

     /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while
     /dev/random will prefer to block and wait for additional entropy to be collected.	With Yarrow, this choice and distinction is not necessary,
     and the two devices behave identically. You may use either.

OPERATION

     The random device implements the Yarrow pseudo random number generator algorithm and maintains its entropy pool.  Additional entropy is fed
     to the generator regularly by the SecurityServer daemon from random jitter measurements of the kernel.  SecurityServer is also responsible
     for periodically saving some entropy to disk and reloading it during startup to provide entropy in early system operation.

     You may feed additional entropy to the generator by writing it to the random device, though this is not required in a normal operating envi-
     ronment.

LIMITATIONS AND WARNINGS

     Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root.  The quality of its output is however dependent on regu-
     lar addition of appropriate entropy. If the SecurityServer system daemon fails for any reason, output quality will suffer over time without
     any explicit indication from the random device itself.

     Paranoid programmers can counteract this risk somewhat by collecting entropy of their choice (e.g. from keystroke or mouse timings) and seed-
     ing it into random directly before obtaining important random numbers.

FILES

     /dev/random
     /dev/urandom

HISTORY

     A random device appeared in the Linux operating system.

Darwin								 September 6, 2001							    Darwin