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 SUSE

platform::shell

platform::shell(n)					       Tcl Bundled Packages						platform::shell(n)

__________________________________________________________________________________________________________________________________________________

NAME

       platform::shell - System identification support code and utilities

SYNOPSIS

       package require platform::shell ?1.1.4?

       platform::shell::generic shell
       platform::shell::identify shell
       platform::shell::platform shell
_________________________________________________________________

DESCRIPTION

       The platform::shell package provides several utility commands useful for the identification of the architecture of a specific Tcl shell.

       This  package  allows the identification of the architecture of a specific Tcl shell different from the shell running the package. The only
       requirement is that the other shell (identified by its path), is actually executable on the current machine.

       While for most platform this means that the architecture of the interrogated shell is identical to the architecture of  the  running  shell
       this  is  not generally true. A counter example are all platforms which have 32 and 64 bit variants and where a 64bit system is able to run
       32bit code. For these running and interrogated shell may have different 32/64 bit settings and thus different identifiers.

       For applications like a code repository it is important to identify the architecture of the shell which will  actually  run  the  installed
       packages, versus the architecture of the shell running the repository software.

COMMANDS

       platform::shell::identify shell
	      This command does the same identification as platform::identify, for the specified Tcl shell, in contrast to the running shell.

       platform::shell::generic shell
	      This command does the same identification as platform::generic, for the specified Tcl shell, in contrast to the running shell.

       platform::shell::platform shell
	      This command returns the contents of tcl_platform(platform) for the specified Tcl shell.

KEYWORDS

       operating system, cpu architecture, platform, architecture

platform::shell 						       1.1.4							platform::shell(n)