Most Unix and GNU/Linux shells implement a flat variable namespace. Korn shell 93 implements a hierarchical variable namespace. This enabled the implementation of an aggregate definition for a shell variable to include subvariables called compound variables. This post tries to explain compound variables in some detail and demonstrate how useful they can be in when dealing with structured data.
|
|
|||||||||||||||||||||||
    |
Recently I was working on a fairly complex JavaScript script relating to floating point conversions for a new Web page. After a while I got tired on trying to debug the problem via a Web browser and decided to see if I could find a JavaScript shell, i.e. a standalone Javascript intrepreter just like Ruby’s irb, Python’s interactive prompt or the Korn shell, which could load and run JavaScript scripts from the command line without having to reload a Web page. First, some background on the JavaScript langauge for those who are unfamilar with the details. JavaScript is a complex full-featured weakly typed object- based functional programming language originally developed by Brendan Eich in 1995 while working on the Netscape Navigator browser.  It is most frequently used in client-side web applications but is also used to enable scripting access to embedded objects in other applications. The langauge has been standardized in the ECMA-262 (ECMAScript) specification. The first version of ECMAScript was published in June 1997, and was partially based on JavaScript v1.2. The current version is Edition 3 (Dec 1999) and work is ongoing on the next edition. Formally, Javascript is a dialect of ECMAScript whose langauge specification is controlled by the Mozilla Foundation. There are other dialects including ActionScript which the scripting language used in Adobe Flash. Javascript is still evolving as a language and several versions are in daily use. The current version is JavaScript 1.8. The JavaScript engine in Firefox is written in C. It was orginally called Javascript Reference (JSRef) but nowadays is known as SpiderMonkey. Other Mozilla products also use this engine and it is available to the public under a MPL/GPL/LGPL tri-license. The current version, SpiderMonkey 1.7, conforms to JavaScript 1.8 which is a superset of ECMA-262 Edition 3. It consists of a library (or DLL) containing the JavaScript runtime (compiler, interpreter, decompiler, garbage collector, atom manager and standard classes) engine. This codebase has no dependencies on the rest of the Mozilla codebase. The codebase also contains the routines for a simple user interface which can be linked to the runtime library in order to make a command line shell. You can download the source code for SpiderMonkey 1.7 here. Aternatively you can use wget,curl or ftp to download the tarball. No build script is provided with this version of SpiderMonkey. Here is how I downloaded, built and smoketest’ed the shell. mkdir mozilla cd mozilla wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz tar xzf js-1.7.0.tar.gz cd js/src make -f Makefile.ref If everything compiles I am a big fan of the POSIX.1 standard. The lastest version of this standard (IEEE Std. 1003.1-2008) was released in December 1st 2008. The formal name for this version of the standard is Portable Operating System Interface (POSIX) Base Specifications, Issue 7. Like its predecessors, IEEE Std. 1003.1-2004 and IEEE Std. 1003.1-2001, it was developed by the Austin Common Standards Revision Group (CSRG), more commonly called the Austin Working Group, which is a joint technical working group established in 1999 to develop and maintain the core open systems interfaces. The working group’s stated approach to specification development is write once, adopt everywhere, with the deliverables being a set of specifications that simultaniously carry the IEEE POSIX designation, The Open Group’s Technical Standard designation, and the ISO/IEC designation. Thus the new version of the specifications is simultaneously ISO/IEC 9945, IEEE Std. 1003.1-2008 and The Open Group Base Technical Standard Specifications, Issue 7. The standard describes the characteristics and facilities of an operating system that are of importance to application developers. It intended, however, to be used by both application developers and system implementors. More precisely, it defines a standard operating system interface and environment, including a shell and utilities to support application portability at the source code level. It contains approximately 4000 pages and is divided into 4 volumes. General definitions,terms, concepts, and interfaces common to all volumes of this standard, including utility conventions and C programming language header definitions, are included in the Base Definitions volume. Definitions for system service functions and subroutines, language-specific system services for the C programming language, function issues, including portability, error handling, and error recovery, are included in the System Interfaces volume. Definitions for a command interpreter (shell) language and various utilities for application developemnt and support are included in the Shell and Utilities volume. The Rational volume contains information that did not fit well into the other volumes, including historical information about the standard and why particular features were included, not included or removed by the working group. The standard contains a base set of interfaces and functionality which is required in all compliant systems, together with a number of option groups. Based on these options and option groups, profiles can be defined which further group the options which are needed for a particular application domain. Some of the option groups contain a lot of functionality, others very little. The size of the |
||||||||||||||||||||||
|
Copyright © 2005-2012 Finnbarr P. Murphy. All Rights Reserved. |
|||||||||||||||||||||||