Sponsored Content
Full Discussion: Boy, is the shell powerful.
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
Old 05-07-2013
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..
 

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... (3 Replies)
Discussion started by: RedVenim
3 Replies

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... (11 Replies)
Discussion started by: pallak7
11 Replies

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... (8 Replies)
Discussion started by: adelsin
8 Replies
GIT-SHELL(1)                                                        Git Manual                                                        GIT-SHELL(1)

NAME
git-shell - Restricted login shell for Git-only SSH access SYNOPSIS
chsh -s $(command -v git-shell) <user> git clone <user>@localhost:/path/to/repo.git ssh <user>@localhost DESCRIPTION
This is a login shell for SSH accounts to provide restricted Git access. It permits execution only of server-side Git commands implementing the pull/push functionality, plus custom commands present in a subdirectory named git-shell-commands in the user's home directory. COMMANDS
git shell accepts the following commands after the -c option: git receive-pack <argument>, git upload-pack <argument>, git upload-archive <argument> Call the corresponding server-side command to support the client's git push, git fetch, or git archive --remote request. cvs server Imitate a CVS server. See git-cvsserver(1). If a ~/git-shell-commands directory is present, git shell will also handle other, custom commands by running "git-shell-commands/<command> <arguments>" from the user's home directory. INTERACTIVE USE
By default, the commands above can be executed only with the -c option; the shell is not interactive. If a ~/git-shell-commands directory is present, git shell can also be run interactively (with no arguments). If a help command is present in the git-shell-commands directory, it is run to provide the user with an overview of allowed actions. Then a "git> " prompt is presented at which one can enter any of the commands from the git-shell-commands directory, or exit to close the connection. Generally this mode is used as an administrative interface to allow users to list repositories they have access to, create, delete, or rename repositories, or change repository descriptions and permissions. If a no-interactive-login command exists, then it is run and the interactive shell is aborted. EXAMPLE
To disable interactive logins, displaying a greeting instead: $ chsh -s /usr/bin/git-shell $ mkdir $HOME/git-shell-commands $ cat >$HOME/git-shell-commands/no-interactive-login <<EOF #!/bin/sh printf '%s ' "Hi $USER! You've successfully authenticated, but I do not" printf '%s ' "provide interactive shell access." exit 128 EOF $ chmod +x $HOME/git-shell-commands/no-interactive-login To enable git-cvsserver access (which should generally have the no-interactive-login example above as a prerequisite, as creating the git-shell-commands directory allows interactive logins): $ cat >$HOME/git-shell-commands/cvs <<EOF if ! test $# = 1 && test "$1" = "server" then echo >&2 "git-cvsserver only handles "server"" exit 1 fi exec git cvsserver server EOF $ chmod +x $HOME/git-shell-commands/cvs SEE ALSO
ssh(1), git-daemon(1), contrib/git-shell-commands/README GIT
Part of the git(1) suite Git 2.17.1 10/05/2018 GIT-SHELL(1)
All times are GMT -4. The time now is 11:03 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy