Boy, is the shell powerful. Post: 302803269

Sponsored Content

The Lounge What is on Your Mind? Boy, is the shell powerful. Post 302803269 by Corona688 on Monday 6th of May 2013 11:02:07 AM

05-06-2013

Registered User

Quote:

Originally Posted by wisecracker

Reading replies to questions, as an amateur, I have learnt a lot from you pros on here.
The shell in any of its guises is serioulsy poweful.

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?

The deep dark secret of high-level languages is that, even if you treat C/C++ as a dark-ages language and eschew it for java/python/shell/CAML/INTERCAL, nearly all the "Good Stuff" your programs depend on(like SOX, and BASH itself) are actually written in it. It's a powerful enough language to build other efficient languages and language addons, a rare feat; hardly anything would be much good without it.

Second, the shell is a good interface to the UNIX system, but a poor interface to other systems where not everything is a file... Imagine you didn't have utilities like SOX or an external /dev/dsp, how simple would your oscilloscope be then?

Shells are bad at networking. Even though BASH and KSH have some networking built into them these days(via a faked /dev/tcp), try building a network server without C help... You can't do it. Too many things missing.

Another thing the shell is poor at is performance. It's great at summoning other programs to do its work for it... not the greatest if you have to sum 3 million numbers in a flash with no outside help.

It's highly subject to system limits, like the length of a command-line, and the maximum length of an environment variable. You happen to get conveniently big ones in LINUX and OSX but aren't always so lucky.

If you don't have access to install things on your system, you will find the shell very limiting. No sox.

Also, you are using nonstandard capabilities of the BASH shell (i.e. dealing with binary data). Imagine you were forced to use an ancient bourne shell, not bash. I don't think you'd consider it quite as fantastic.

Last edited by Corona688; 05-06-2013 at 12:14 PM..

These 2 Users Gave Thanks to Corona688 For This Post:

Corona688

View Public Profile for Corona688

Visit Corona688's homepage!

Find all posts by Corona688

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 CENTOS

git-shell

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

SEE ALSO

       ssh(1), git-daemon(1), contrib/git-shell-commands/README

GIT

       Part of the git(1) suite

Git 1.8.3.1							    06/10/2014							      GIT-SHELL(1)