|
Quick and Dirty Vimdiff Tutorial |
vote
 |
|
A quick how to for the famous Vimdiff utility. It lists the most relevant shortcuts and a screenshot that shows Vimdiff in action.
Vimdiff is a tool that comes bundled with Vim and its a wonderful tool for comparing code and merging changes. read more... |
|
| | permapage | score:9136 | -jinx_kid, September 19, 2008 (Updated: September 20, 2008) |
|
PHP: Associative Array Tricks |
vote
|
|
Ten tricks for manipulating associative arrays in PHP...
The associative array -- an indispensable data type used to describe a collection of unique keys and associated values -- is a mainstay of all programming languages, PHP included. In fact, associative arrays are so central to the task of Web development that PHP supports dozens of functions and other features capable of manipulating array data in every conceivable manner. Such extensive support can be a bit overwhelming to developers seeking the most effective way to manipulate arrays within their applications. In this article, I'll offer 10 tips that can help you shred, slice and dice your data in countless ways. read more... |
|
| | mail this link | permapage | score:9109 | -Ray, December 12, 2010 |
|
Unix: Shell Script Wrapper Examples |
vote
|
|
Shell script wrappers can make the *nix command more transparent to the user. The most common shell scripts are simple wrappers around third party or system binaries. A wrapper is nothing but a shell script that includes a system command or utility.
Linux and Unix like operating system can run both 32bit and 64bit specific versions of applications. You can write a wrapper script that can select and execute correct version on a 32bit or 64bit hardware platform. In cluster environment and High-Performance computing environment you may find 100s of wrapper scripts written in Perl, Shell, and Python to get cluster usage, setting up shared storage, submitting and managing jobs, backups, troubleshooting, invokes commands with specified arguments, sending stdout to stdout and stderr to stderr and much more.
In this post, I will explains how to create a shell wrapper to enhance the basic troubleshooting tool such as ping and host. read more... |
|
| | mail this link | permapage | score:9106 | -nixcraft, June 24, 2012 |
|
Space Tyrant: A threaded game server project in C |
vote
|
|
[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]
[Update, March 21, 2007: A Space Tyrant has its own website! It's small but growing and will provide quick access to the latest code and developments in the ST universe.]
Space Tyrant: Today we kick off a new multithreaded, network socket programming project which we will call Space Tyrant. Our mission is to write an open source, multiplayer, networked, strategy game in the C programming language. The goal of this project is to make a solid code base which implements a simple space trading game upon which other games can then be built. The game will be a subset of The Last Resort (TLR) that currently runs at [offline]. This project will be a learning exercise for me as well as for any interested readers. The current state of the source code will be released with each article update.
The game design: While my TLR game consists of over 25,000 lines of C source code and supports a web interface as well as telnet and a graphical client, this code will be far smaller and simpler. It will initially only support telnet and will implement a far simpler game design.
Players will be able to telnet into the game, create an account, and play in a universe that contains ports, planets, as well as other players. Each player will be issued a starship, some cargo holds, and an amount of starship fuel. Additional fuel will be issued hourly and will accumulate in the starship. Fuel will be used to move the ship between sectors -- locations within the game universe -- and to dock with ports. Once a ship runs out of fuel it can't move at all until new fuel is issued.
Players will be able to buy and sell commodities (Iron, alcohol, and hardware) between the three different kinds of ports. Each port type will sell one of the three commodities and buy the other two. Prices will be based on supply and demand with rarely-used ports offering the better prices.
With the money players earn trading they will be able to buy more cargo holds to make their ships more efficient for trading. They will also be able to buy fighters -- small military drones -- that can be used to attack other ships or deployed to guard a sector and its contents. The fighters carried with a ship will guard it against attacks from other players.
Games will run for a predetermined length of time, then reset and start anew.
The programming model: Now, on to the software design. I've compared and considered various models for the server design. TLR is based on the forking model using inetd or xinetd to handle the listening and forking. While the forking model is inherently distributable to multiple processors, it introduces inefficiencies (forking multiple processes) and makes interprocess communications more difficult and slower.
Next, I considered a non-blocking, single process model. In this approach, one process handles everything in a single thread. It would use non-blocking IO (read and write functions that never wait for completion but, rather, return immediately if they aren't ready to read or write actual data). The thttpd web server is an example of a non-blocking, single process server. It's extremely fast and efficient. However, this model is quite complicated to code, and, I believe would make it more likely to introduce subtle timing bugs.
Next, I considered a pure multithreaded, single process model with a thread for each player. While appealing in many ways, this model would require the same kind of coordination between threads that the forking model requires between processes. Such interprocess communication would be simplified in that the various threads share memory, but the coordination issues otherwise remain the same.
Last, I considered another multithreaded model, this time with only IO threads for each user and a single thread that implements all game logic. While that one central thread might someday be a bottleneck that limits scalability on large SMP systems, it does distribute the IO on any additional processors that might be present, and requires minimal coordination. In short, this model combines the logic simplicity of the non-blocking single process model with the coding simplicity of the threaded model, while separating the IO from the main logic. There will also be two other simple threads in this model. There will be a thread that listens for new connections and spawns the IO threads for each new connection. There will also be a thread that writes the data to disk periodically.
This is the approach that I intend to take for this project. The code will be written for both Linux and Mac OS X.
More info: I have set up an email address for programmers following this series to provide recommendations, bug reports, and other feedback. Send email about this project to spacetyrant [at] librenix.com. |
|
| | mail this link | permapage | score:9104 | -Ray, March 18, 2005 (Updated: July 26, 2008) |
|
Python Client/Server Tutorial |
vote
|
|
A tiny Python tutorial...
This application can easily be coded in Python with performance levels of thousands of transactions per second on a desktop PC. Simple sample programs for the server and client sides are listed below, with discussions following read more... |
|
| | permapage | score:9098 | -Ray, June 22, 2009 |
|
perl1line.txt: A handy Perl script collection |
vote
|
|
The ultimate goal of the Perl One-Liners Explained article series was to release the perl1line.txt file. Last week I finished the series and now I am happy to announce perl1line.txt - a collection of handy Perl one-liner scripts.
The perl1line.txt file contains over a hundred short Perl one-line scripts for various text processing tasks. The file processing tasks include: changing file spacing, numbering lines, doing calculations, creating strings and arrays, converting and substituting text, selective printing and deleting of certain lines and text filtering and modifications through regular expressions.
The latest version of perl1line.txt is always at:http://www.catonmat.net/download/perl1line.txt Enjoy! It took me over 3 years to write all the one-liners down. read more... |
|
| | mail this link | permapage | score:9096 | -pkrumins, November 21, 2011 |
|
Sysadmin Shell Scripting |
vote
|
|
This three-part series covers basic, intermediate and advanced shell scripting techniques for system administrators.
A working knowledge of shell scripting is vital if someone wants to become good at system administration tasks. Since this tutorial tackles topics that assume a basic understanding of shell scripting, we strongly urge you to take a look at our Shell Scripting: The Basics article first…
One important aspect of shell scripting is file-oriented utility. A file-oriented utility is basically used as a filter in a pipe.
We can add a ‘-’ to get a more useful result. That is, when we have ‘file -’, the shell waits for the user input and analyses it. read more... |
|
| | mail this link | permapage | score:9074 | -Ray, December 17, 2010 |
|
Detailed Error Handling In Bash |
vote
|
|
| Shell scripts are often running as background processes, doing useful things without running in a visible shell. To write such scripts can be quite painful, as all errors occur out of sight as well. While log files can hold a lot of information, finding the relevant information is a bit trickier. My solution is to log only the errors with all the details to a small database. This database contains tables for the message, the corresponding stack trace and the important environment variables. I have chosen for an SQLite database in this howto, but the same principle works with other databases as well. read more... |
|
| | mail this link | permapage | score:9074 | -falko, February 21, 2013 |
|
Sustitution with sed |
vote
|
|
| The Linux utility sed provides a great way to substitute text strings in a file. Using the "s" option and by listing the current string and the string to use as the new text allows sed to perform this task. read more... |
|
| | permapage | score:9072 | -aweber, August 3, 2011 |
|
Tutorial: Install the Aptana AJAX IDE on Ubuntu |
vote
|
|
| This tutorial shows how to install the Aptana IDE on an Ubuntu Edgy Eft system. The Aptana IDE is a free, open-source, cross-platform, JavaScript-focused development environment for building Ajax applications. It features code assist on JavaScript, HTML, and CSS languages, FTP/SFTP support and a JavaScript debugger to troubleshoot your code. read more... |
|
| | permapage | score:9062 | -falko, March 14, 2007 |
|
The Real Microsoft Monopoly |
vote
|
|
The courts have ruled that Microsoft holds a monopoly position in Intel PC Operating Systems. Business users have long been aware of Microsoft's lock on office productivity applications that require them to use MS Office in order to remain compatible with their business partners and customers. And web-surfing users are now using Internet Explorer in a ratio of about 8:1 over alternative browsers.
But one aspect of Microsoft's monopoly is more fundamental than any of those; the investment in skill, experience, training, and tools of Windows software developers themselves.
Those programmers, who have logged many long sessions of coding for the Windows environments, and with their deep immersion in its assumptions, tools, and API's, represent millions of person-years of Microsoft assets.
For years it has been a difficult decision for a professional developer to choose an environment other than Windows. The scale of that market dwarfs its competitors and opens to developers many more specialty markets than any alternative platform. Further, the sheer size of the Windows installed base is seen as a hedge against market change. Windows is perceived as a platform that will be with us for a long time to come.
Because it can take years of effort to reach the highest levels of productivity in a complex development environment, Windows-specialized programmers have, through economic necessity, been unable to switch to a different platform. With a large majority of developers writing code for Windows, the continued dominance of Windows applications was also assured. The monopoly was elegantly self-perpetuating.
Many companies, failing to appreciate the depth of Microsoft's monopoly and its determination to defend it, squandered valuable resources probing Microsoft's markets for an opportunity. After several spectacular failures, it seemed nearly impossible for such a locked market to break free of this cycle.
It seemed impossible, that is, until recently. Windows is no longer leading the growth curve among operating systems. The near perfect seal at the margins of the monopoly, it turns out, is only effective against competitors with a requirement to make money.
While Microsoft once made the fending off of mighty IBM look easy, the Linux phenomenon presents a very different kind of challenge. It needs no profits, corporate partnerships, or investors in order to succeed. Linux depends only on hobbyists' passion for programming and their self-imposed standards of quality in their own work. Further, the Linux community seems to draw motivation from its dissatisfaction with the computing landscape that Microsoft has created.
This noncorporate juggernaut has grown so large that it is spilling into commercial markets on many fronts. Now, with the additional support of several large corporations, the expansion rate of Linux could actually accelerate.
Much of the continued growth of Linux will come at the expense of Microsoft. Others will lose business along the way, of course, but the ubiquitous presense of Microsoft astride the market presents many targets that are simply too broad to miss.
Unfortunately for Windows programmers, at some point the rapid growth of Linux will force the saturated Windows market to start shrinking. Soon thereafter, the seller's market for Windows programming services will become a buyer's market -- and pay scales will begin to drop. Although the computer industry has experienced many of these disruptions in the past as new competition entered the market, this will be the largest such contraction by far.
Confidence in the impenetrable market lock of MS Windows is slowly fading. Some years from now when this trend reversal is complete and documented, we will look back to a single turning point to call the end of Windows' dominance. I'm making my pick a little prematurely. I think the critical point was IBM's decision to support and invest heavily in Linux. |
|
| | mail this link | permapage | score:9052 | -Ray, July 9, 2001 (Updated: April 18, 2007) |
|
Space Tyrant: A multiplayer network game for Linux |
vote
|
|
Since the last release of Space Tyrant, it has gained some actual game-like functionality. The new code can be downloaded from st2.c. Download it as well as the shell script you’ll need to compile it: makeit2.sh.
It’s now possible to connect to the game via telnet and to create an account, log in, and be issued a ship. Once you’re logged in, there is a universe to explore filled with ports for buying and selling goods and planets for scooping free goods. From those trading activities you can earn money, called microbots. Other than trading to earn more money, you only use your microbots to buy fighters -- which you can use to attack other players or the neutral fighters that guard some sectors.
The neutral fighters are only good for parking under while you’re not playing. They afford a little bit of free protection for your ship since no one can attack you until they first destroy the neutral fighters. Note that you can attack other players whether they are logged in or not and any fighters with their ship will automatically try to defend them.
Each player starts out with a specific supply of fuel, called antimatter. Each minute a small amount of additional antimatter is issued by a function called updatefuel(). If you’re not logged in, fuel just accumulates in your ship. This continuous allocation of fuel makes Space Tyrant a type of turn-based game. Unlike traditional turn-based games, however, you can play your fuel all at once or a little at a time and completely independently of how and when other players play.
You can also talk to other players on the radio. There is only one channel so everyone who is logged in hears everything that is said on the radio.
The game isn’t yet playable in any reliable sense, however, because it doesn’t yet back up and reload the data from disk files. The software creates an instance of the game when you run it and it remains running until you stop it or the system goes down. There is also no way to establish a time limit on a game.
That’s pretty much the extent of the functionality changes. Now, on to the code.
First, there is a login function. That function looks in the player database struct and, if the player name doesn’t already exist, it creates an account there. If the name does exist, it prompts for a password, matches it against the stored password, and logs you in if the two match. There is not yet a way to change your password.
Once a player is logged in, he is faced with a sector description and a ‘choice:’ prompt. Any character that the player types at this prompt is immediately acted on as if it were a command. There is a string called ‘commlist’, short for command list, containing the letters and characters that are used as commands. A function pointer array, ‘fp[]()’, is used to store the locations of the command functions. Another function called ‘commscan()’ looks up the command letter typed and returns an index into the fp[]() function pointer array. This combination of the commlist string, the commscan function, and the fp function pointer array constitute the command processing loop of the game, as shown below:
userndx=commscan(
tolower(
threc[th].inbuf
[threc[th].inptr][0]
),commlist
);
result=fp[userndx](th);
These lines are embedded in a loop where each user’s input thread, represented by the variable ‘th’, is examined for new input. The new input arrives in string called inbuf. Since each thread has several buffers, an index called inptr is used to keep track of which one is currently being processed.
And, as described above, commscan is used to extract the appropriate function index and place it in a variable called ‘userndx’. Then, userndx is used to index into the fp function pointer array and the thread index (th) is passed to the appropriate command-processing function.
There’s a small amount of misdirection in that first line but, once understood, it becomes trivial to add additional commands. Basically, you just need to replace the placeholder function, ‘nullrtn’, with your new function name adjacent to the command letter you select in the fp[]() definition list.
The new functions are discussed below.
makemap()
In keeping with the evolving game nature of this project, several actual game functions have been added. The first new function, makemap(), builds a 20,000-sector single-galaxy universe and populates it with objects. By changing the GAMESIZE constant, you can build a universe of arbitrary size, but make sure you don’t try to build a universe so big as to consume too much of your system’s memory. I’ve tested universes of up to 1,000,000 sectors, which seem to work just fine. The makemap() function randomly puts ports, planets, fleets of neutral fighters, and nebulas in various sectors throughout the universe, and interconnects the sectors with randomly-generated one-way ‘warps’. Note that planets and ports are randomly given varying productivity's and random initial inventories of our three commodities: Iron, Alcohol, and Hardware.
Note that makemap() builds each sectors array of six warps, sorts them into ascending order, and then looks for duplicate warps. If any duplicates are found, it decrements the loop-controlling variable and simply rebuilds that entire sector from scratch. The sorted warps are a convention that we will maintain throughout the project. Each new galaxy type that we add in the future will adhere to that convention and other functions (and users) will be allowed to assume that warps are in ascending order.
command()
We have added a function to simply list the implemented commands and a short line of description. For now, the function is attached to the command letters ‘?’ and ‘H’ via the function pointer array and the commlist array. This function is mostly useful to illustrate a design limitation. The output of any single sprintf buffer-building function cannot exceed the MAXLINE buffer size constant. This function produces a single buffer out output very near the current 511-byte limit and will soon have to be split to produce two buffers of output. Assuming, of course, that we don’t increase the MAXLINE buffer size.
jettison()
The ‘J’ command activates the jettison() function. It’s only purpose is to dump any cargo out of your cargo holds. It illustrates the method we use to let a function that requires multiple characters of input -- or simple confirmation -- to temporarily turn off command processing and send the next character of input back to it. Jettison requires confirmation so that you don’t accidentally dump your cargo just by hitting the J key. (Since all commands operate as ‘hot’ keys you do not have to hit the [Enter] key to activate a command -- each command immediately executes as soon as you press a key.)
Each command function has the ability to set the thread’s control variable to it’s own command letter. That way, the command processing loop can simply check ‘control’ pass the next buffer of input directly to whichever function is indicated.
warprtn()
jumprtn()
The warprtn and jumprtn functions process requests to move to another sector. warprtn() processes the commands 1, 2, 3, 4, 5, and 6, which represent a user’s request to move to the first through the sixth sector number in the warp list, respectively. jumprtn() processes requests to move to a randomly selected sector in the warp list via the ‘-’ (or ‘=’) key. jumprtn() also implements commands to move to the next larger sector, the next smaller sector, as well as the largest and smallest sector number via the ‘.’, ‘,’, ‘>’, and ‘game design and the programming model. The second article discusses the IO handling code and more of the details of the programming model.]
[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]
[Update, March 21, 2007: Space Tyrant now has a website of its own!. This site is new but growing and will be the quickest way to find new information and code on the Space Tyrant project.] |
|
| | mail this link | permapage | score:9052 | -Ray, May 30, 2005 (Updated: March 21, 2007) |
|
Bash: Use the Test Command for multiple aspects |
vote
|
|
| The Bash shell has a builtin test command that can be used to check for multiple aspects in a script. This exercise helps you build a script that checks to see if a file exists and if it does, checks to see if it is writable. read more... |
|
| | permapage | score:9047 | -aweber, December 4, 2011 |
|
Debugging Shell Scripts |
vote
|
|
| Learning how to find the errors in your shell scripts is an important skill for successful shell scripting. The debug options in the Bash shell can help with that. read more... |
|
| | permapage | score:9041 | -aweber, February 2, 2012 |
|
Integrate XCache into PHP5 |
vote
|
|
| This guide explains how to integrate XCache into PHP5 on a Fedora 13 or CentOS 5.5 system (with Apache2). From the XCache project page: "XCache is a fast, stable PHP opcode cacher that has been tested and is now running on production servers under high load." It's similar to other PHP opcode cachers, such as eAccelerator and APC. read more... |
|
| | permapage | score:9023 | -falko, September 9, 2010 |
|
Open source Cloud Computing with PHP and MySQL |
vote
|
|
| In this article you will learn how Aptana makes it easy to develop applications based on PHP and MySQL, and how to deploy them to the cloud. Also explore some of the critical design differences between a cloud application and a traditional N-tier application. read more... |
|
| | permapage | score:9022 | -solrac, May 18, 2009 |
|
Tutorial: MySQL Linux C API |
vote
|
|
MySQL database does support C program API just like PHP or Perl API.
The C API code is distributed with MySQL. It is included in the mysqlclient library and allows C programs to access a database.
Many of the clients in the MySQL source distribution are written in C. If you are looking for examples that demonstrate how to use the C API, take a look at these clients. You can find these in the clients directory in the MySQL source distribution.
This tutorial provides a sample MySQL C program and step by step compilation instructions to kick start MySQL programming via C API. read more... |
|
| | mail this link | permapage | score:9017 | -nixcraft, June 1, 2007 |
|
Space Tyrant: A threaded C game project: First Code |
vote
|
|
First code: This is the first code release of Space Tyrant. This is an early stage of development and, at this point, only implements the listening thread, the two IO threads for each player connection, and a skeletal game logic thread that does little beyond proof-of-concept code.
The design of the code was discussed in this article so you should probably go back and read that article if this is your first brush with this project.
The first code release -- what we will be discussing in this article -- is online as spacetyrant1.c. Download it as well as the shell script you’ll need to compile it: makeit1.sh. The script should work under both Linux and Mac OS X. The code will require a single line change to compile under Mac OS X. Search the code for the string OSX to find the line to decomment and the corresponding line to comment out.
Currently, the program allows multiple people to connect using telnet and echos anything they type to all other connected sessions. Some familiarity with the C programming language will be assumed in this article and those to follow.
Configuration constants: There are several ‘configuration constants’ defined by #define statements. The key constants and their meanings are:
MAXTH: This number represents the maximum number of users that can connect simultaneously. This constant is used to set limits on loops and to define the number of elements in various arrays. This number must be a power of 2.
MAXTHBITS: This is simply the number of bits necessary to form an unsigned int to index into arrays of MAXTH size. This number is used to declare bit fields for use with various items that occur MAXTH times. In the code we use a MAXTH of 256 and since 2^8 equals 256, MAXTHBITS is set to 8. Note that if you change MAXTH, you must make an appropriate change to MAXTHBITS!
MAXBUF: This is the number of buffers used in various places. For example, the input threads each get MAXBUF numbers of buffers.
MAXBUFBITS: This number matches MAXBUF in that it is the number of bits necessary to express the number MAXBUF in the same way that MAXTHBITS relates to MAXTH.
MAXLINE: This is the maximum length (in bytes) that is allowed for network input and output. The IO buffers, for example, are declared to be size MAXLINE + 1. The ‘+ 1’ is to allow room for a terminating 0.
RADPAD: This is added to MAXLINE to determine the length of a radio buffer. Radio buffers need to be larger than IO buffers since they must allow room for headers.
Data structures: Next, we declare a struct to contain most of the data associated with each thread. Note that this struct contains no player-specific data; it is used only to contain the data necessary to define an input thread and an output thread used to define one user connection. ‘threc’, as we will call the struct, will be an array with MAXTH elements. It will contain the thread ID of both the input and output threads, the timestamp of the last input from the input thread, the number of the socket descriptor, and various flags and indexes that will be used to coordinate the activities of the input, output, and game logic threads. Look at the code comments themselves for details on the variables.
Note that MAXBUFBITS is used to declare the size of inndx, outndx, inptr, and outptr. These variables, when incremented past the number of buffers, wrap back to zero, making it easy to implement ring buffers. That is why the MAXBUF number must be a power of 2.
The thread functions: In this program main() has two primary functions. First, it calls any initialization functions and clears the various data structures and spawns any other permanent threads. Second, it goes into an endless loop of accepting user connections and spawning IO threads to handle the newly connected users.
The next thread function, gameloop(), has the hard job. It constantly loops though the input buffers, looks for input that needs to be processed, and does it. While looping around the buffers, it also looks for input threads that have gone idle and terminates (‘reaps’) them. Currently, the only input processing it does to call a function named broadcast() with any data it finds in the input buffers. The broadcast() function simply copies the input to output buffers. This bit of processing is for proof-of-concept purposes only and will be replaced by actual game logic as it is developed.
The last important thread functions, userin() and userout(), exist in multiple pairs to perform network input and output duties for each connected user. The userin() thread reads the network connection and loads data into the next available input buffer (‘inbuf’). It then timestamps it, and goes back to waiting for more input. The userout() thread loops continously waiting for anything to appear in the next output buffer (‘outbuf’). When new data is placed in an output buffer by the gameloop() thread, userout() writes it to the user’s network socket.
Note that because userout() and gameloop() loop continously, they sleep after each ‘idle’ loop. That is, when they pass through their logic loop and find no actual work to do, they call the usleep() function to sleep a tiny fraction of a second. This sleeping prevents them from consuming unnecessary processor cycles.
[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.] |
|
| | mail this link | permapage | score:9003 | -Ray, March 27, 2005 (Updated: June 25, 2005) |
|
Fix concurrency bugs with GPars |
vote
|
|
| The shift toward multicore processing has fueled an interest in concurrent programming models like fork/join, actors, agents, and executors. While these models originated within different programming languages, many of them are encapsulated in GPars, a Groovy-based concurrency library. With Alex Miller as your guide, learn how to resolve concurrency problems using techniques drawn from both the functional and object-oriented programming worlds — and do it all using Groovy's familiar, Java-friendly syntax. read more... |
|
| | mail this link | permapage | score:8969 | -solrac, September 14, 2010 |
|
24 one hour Linux shell scripting lessons |
vote
|
|
Yes, you really can learn Unix/Linux shell scripting in 24 hours. And, what works for the traditional Unix Bourne shell also works for the GNU Bourne Again SHell, bash, the virtual standard for Linux.
One of the most powerful standard programs available in UNIX is the shell. The shell is a program that provides you with a consistent and easy-to-use environment for executing programs in UNIX. If you have ever used a UNIX system, you have interacted with the shell.
The main responsibility of the shell is to read the commands you type and then ask the UNIX kernel to perform these commands. In addition to this, the shell provides sophisticated programming constructs that enable you to make decisions, repeatedly execute commands, create functions, and store values in variables.
This book concentrates on the standard UNIX shell called the Bourne shell. read more... |
|
| | mail this link | permapage | score:8963 | -Ray, December 19, 2005 (Updated: March 24, 2007) |
|
|
