US7620959B2 - Reflection-based processing of input parameters for commands - Google Patents

Reflection-based processing of input parameters for commands Download PDF

Info

Publication number
US7620959B2
US7620959B2 US10/438,234 US43823403A US7620959B2 US 7620959 B2 US7620959 B2 US 7620959B2 US 43823403 A US43823403 A US 43823403A US 7620959 B2 US7620959 B2 US 7620959B2
Authority
US
United States
Prior art keywords
parameter
command
directive
directives
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US10/438,234
Other versions
US20040230987A1 (en
Inventor
Jeffrey P. Snover
James W. Truher, III
Daryl W. Wray
Kaushik Pushpavanam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SNOVER, JEFFREY P., PUSHPAVANAM, KAUSHIK, TRUHER, JAMES W. III, WRAY, DARYL W.
Priority to US10/438,234 priority Critical patent/US7620959B2/en
Priority to EP04009697A priority patent/EP1477897A3/en
Priority to KR1020040032922A priority patent/KR100995199B1/en
Priority to JP2004142832A priority patent/JP4889204B2/en
Priority to CNB2004100434914A priority patent/CN100464294C/en
Priority to US10/883,492 priority patent/US7624401B2/en
Publication of US20040230987A1 publication Critical patent/US20040230987A1/en
Publication of US7620959B2 publication Critical patent/US7620959B2/en
Application granted granted Critical
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • EFIXED CONSTRUCTIONS
    • E06DOORS, WINDOWS, SHUTTERS, OR ROLLER BLINDS IN GENERAL; LADDERS
    • E06BFIXED OR MOVABLE CLOSURES FOR OPENINGS IN BUILDINGS, VEHICLES, FENCES OR LIKE ENCLOSURES IN GENERAL, e.g. DOORS, WINDOWS, BLINDS, GATES
    • E06B3/00Window sashes, door leaves, or like elements for closing wall or like openings; Layout of fixed or moving closures, e.g. windows in wall or like openings; Features of rigidly-mounted outer frames relating to the mounting of wing frames
    • E06B3/30Coverings, e.g. protecting against weather, for decorative purposes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G06F9/45512Command shells
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B32LAYERED PRODUCTS
    • B32BLAYERED PRODUCTS, i.e. PRODUCTS BUILT-UP OF STRATA OF FLAT OR NON-FLAT, e.g. CELLULAR OR HONEYCOMB, FORM
    • B32B33/00Layered products characterised by particular properties or particular surface features, e.g. particular surface coatings; Layered products designed for particular purposes not covered by another single class
    • EFIXED CONSTRUCTIONS
    • E06DOORS, WINDOWS, SHUTTERS, OR ROLLER BLINDS IN GENERAL; LADDERS
    • E06BFIXED OR MOVABLE CLOSURES FOR OPENINGS IN BUILDINGS, VEHICLES, FENCES OR LIKE ENCLOSURES IN GENERAL, e.g. DOORS, WINDOWS, BLINDS, GATES
    • E06B3/00Window sashes, door leaves, or like elements for closing wall or like openings; Layout of fixed or moving closures, e.g. windows in wall or like openings; Features of rigidly-mounted outer frames relating to the mounting of wing frames
    • E06B3/04Wing frames not characterised by the manner of movement
    • E06B3/06Single frames
    • E06B3/08Constructions depending on the use of specified materials
    • E06B3/20Constructions depending on the use of specified materials of plastics

Definitions

  • System administration of multi-user computer systems is very specialized.
  • the system administrators who are responsible for system administration are expected to know and understand commands that use inconsistent syntaxes, error reporting, and the like. These inconsistencies between the commands occur because the commands are written by several different software developers, each using their own style. The inconsistencies cause difficulties for the system administrators.
  • One difficulty relates to the usability of the commands. Having inconsistent commands makes system administration more difficult to learn and use. For example, some developers may prefer to use dashes (“-”) between parameters, others may prefer forward slashes (“/”), and still others may prefer to use another unique syntax. The developers may each have their own style in reporting error messages too. Thus, the system administrator must know the syntax for each command and learn the format of each error message.
  • Another difficulty relates to the maintenance of the commands. For example, when the developer who wrote one of the commands leaves, someone else must discover the logic that was used. In order to discover the logic, the other developer must look at the code itself or look at documentation about the command. Neither of these methods is very desirable.
  • the present invention is directed at a reflection-based shell that provides reflection-based processing of input parameters for a command.
  • the reflection-based processing includes parsing, data generation, data validation, object encoding, object processing, documentation, and the like.
  • the reflection-based shell provides a mechanism for specifying a grammar for the input parameters using a class.
  • Third party developers use the class to specify a grammar for their commands.
  • the present invention receives a parsable stream.
  • the parsable stream may be obtained from a command line, voice input, a script, and the like.
  • the parsable stream includes a command and at least one parameter. Based on the parsable stream, definitional information that describes an expected parameter for the command is retrieved.
  • an object is created (i.e., an instance of the class created by the developer).
  • the object stores the at least one parameter in a format in accordance with the description of the expected parameter.
  • the object is then passed to the command, which does its unique processing.
  • the definitional information may include directives that specify actions to be performed on the parsable stream, such as how to map the parameters to the expected parameter, how to obtain the parameters (e.g., interactive), and the like.
  • the directives may also include actions related to parsing, validation, documentation, data generation, and data processing.
  • one advantage of the present invention is that command developers may easily specify a grammar for the input parameters to their command without needing to write the logic that parses the command line to get the input parameters or that validates the input parameters. In so doing, the present invention reduces the amount of code developers need to write and allows the syntax for commands to be more consistent, yet quite versatile.
  • FIG. 1 illustrates an exemplary computing device that may be used in one exemplary embodiment of the present invention.
  • FIG. 2 is a functional flow diagram illustrating the processing of a command line through a parser and an engine within a reflection-based shell in accordance with the present invention.
  • FIG. 3 is one embodiment for a data structure for specifying a grammar for input parameters for a command in accordance with the present invention.
  • FIG. 4 is a logical flow diagram illustrating an exemplary process for handling input parameters entered on the command line within the reflection-based shell of the present invention.
  • the present invention is directed at a reflection-based shell that provides reflection-based processing of input parameters for a command.
  • the present invention minimizes the amount of code that third party developers need to write and minimizes the amount of knowledge that system administrators need to know in order to perform system administrative tasks. Therefore, the present invention significantly reduces system administrative tasks.
  • the present invention provides a more consistent syntax for input parameters, and provides common functionality for the processing associated with the input parameters.
  • FIG. 1 illustrates an exemplary computing device that may be used in one exemplary embodiment of the present invention.
  • computing device 100 typically includes at least one processing unit 102 and system memory 104 .
  • system memory 104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two.
  • System memory 104 typically includes an operating system 105 , one or more program modules 106 , and may include program data 107 .
  • the operating system 105 includes a command processor 130 that executes operating system commands.
  • the command processor 130 includes a shell 131 (i.e., the command processor interface) that accepts the operating system commands.
  • the shell may display a command prompt, may display a graphical user interface, or any other means for inputting and interpreting user input.
  • the shell 131 verifies that the entered commands are valid and sends the verified commands onto another part of the command processor 130 for execution. This basic configuration is illustrated in FIG. 1 by those components within dashed line 108 .
  • Computing device 100 may have additional features or functionality.
  • computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape.
  • additional storage is illustrated in FIG. 1 by removable storage 109 and non-removable storage 110 .
  • Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • System memory 104 , removable storage 109 and non-removable storage 110 are all examples of computer storage media.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 100 . Any such computer storage media may be part of device 100 .
  • Computing device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc.
  • Output device(s) 114 such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.
  • Computing device 100 may also contain communication connections 116 that allow the device to communicate with other computing devices 118 , such as over a network.
  • Communication connections 116 is one example of communication media.
  • Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
  • the term computer readable media as used herein includes both storage media and communication media.
  • FIG. 2 is a functional flow diagram illustrating the processing of a command line 250 through a parser 202 and an engine 204 within a reflection-based shell 200 in accordance with the present invention.
  • the exemplary command line 250 pipelines several commands (i.e., process command 260 , where command 262 , sort command 264 , and table command 266 ). However, the following discussion focuses on the reflection-based processing of input parameters for one command (e.g., where command 262 ). The reflection-based processing for the other commands is performed in a similar fashion.
  • the command line 250 may pass input parameters to any of the commands (e.g., “handlecount> 400 ” is passed to the where command 262 ).
  • the process command 260 does not have any associated input parameters.
  • each command was responsible for parsing the input parameters associated with the command, determining whether the input parameters were valid, and issuing error messages if the input parameters were not valid. Because the commands were typically written by various program the syntax for the input parameters on the command line were not very consistent. In addition, if an error occurred, the error messages, even for the same error, were not very consistent between the commands.
  • a “ls” command and a “ps” command have many inconsistencies between them. While both accept an option “-w”, the “-w” option is used by the “ls” command to denote the width of the page, while the “-w” option is used by the “ps” command to denote print wide output (in essence, ignoring page width).
  • the help pages associated with the “ls” and the “ps” command have several inconsistencies too, such as having options bolded in one and not the other, sorting options alphabetically in one and not the other, requiring some options to have dashes and some not.
  • the reflection-based shell 200 provides a syntax (e.g., grammar), a corresponding semantics (e.g., a dictionary), and a reference model to enable developers to easily take advantage of common functionality provided by the reflection-based shell 200 .
  • a syntax e.g., grammar
  • a corresponding semantics e.g., a dictionary
  • a reference model to enable developers to easily take advantage of common functionality provided by the reflection-based shell 200 .
  • a “command” refers to a stand-alone executable program.
  • a “commandlet” or “cmdlet” refers to programs that are considerably smaller than commands.
  • each cmdlet defines a noun-verb pair (e.g., get/process in command line 250 ).
  • cmdlet when referring to a command written in accordance with the present invention.
  • command may be used to refer to cmdlet.
  • Input parameter refers to input-fields for a cmdlet.
  • Argument refers to an input parameter passed to a command or cmdlet that is the equivalent of a single string in the argv array or passed as a single element in a RequestObject.
  • a RequestObject refers to a mechanism for specifying a grammar for the cmdlet.
  • An argument is one of an option, an option-argument, or an operand following the command-name. Examples of arguments are given based on the following command line: findstr/i/d: ⁇ winnt; ⁇ winnt ⁇ system32 aa*b *.ini.
  • “findstr” is argument 0
  • “/i” is argument 1
  • “/d: ⁇ winnt; ⁇ winnt ⁇ system32” is argument 2
  • “aa*b” is argument 3
  • “*.ini” is argument 4 .
  • An “option” is an argument to a command or cmdlet that is generally used to specify changes to the program's default behavior.
  • “/i” and “/d” are options.
  • An “option-argument” is an input parameter that follows certain options. In some cases, an option-argument is included within the same argument string as the option. In other cases, the option-argument is included as the next argument.
  • “winnt; ⁇ winnt ⁇ system32” is an option-argument.
  • An “operand” is an argument to a command or cmdlet that is generally used as an object supplying information to a program necessary to complete program processing. Operands generally follow the options in a command line. Referring to the example command line above again, “aa*b” and “*.ini” are operands.
  • a “parsable stream” includes the arguments.
  • Class members refers to elements, such as sub-classes, fields, constants, methods, structures, properties, arrays, indexers, interfaces, events, exceptions, and the like.
  • a “directive” refers to a metadata attribute.
  • a “category” refers to a set of particular types of directives.
  • the reflection-based shell of the present invention provides several categories of directives, such as parsing directives, data generation directives, and the like. Within each category, the reflection-based shell provides several directives. The categories and the directives may be extended by the software developers.
  • parser 202 parses a parsable stream (e.g., command line 250 ) into RequestObjects 220 - 226 (e.g., where request 222 ). Each RequestObject 220 - 226 is associated with one of the cmdlets 260 - 266 . Briefly, described in detail below in conjunction with FIG. 3 , the RequestObjects 220 - 226 provide a means or mechanism for a developer to specify a grammar for the input parameters to the cmdlet. The RequestObject is passed to the corresponding cmdlet executable (e.g., where executable 232 ). However, as will be described below in conjunction with FIG.
  • parser 202 and engine 204 performs various processing on the input parameters specified on the command line 200 before passing the RequestObject to the cmdlet executable.
  • the processing includes parsing, parameter validation, data generation, parameter processing, parameter encoding, and parameter documentation. Because parser 202 and engine 204 perform common functionality on the input parameters on the command line, the reflection-based shell 200 is able to issue consistent error messages to users.
  • the executable cmdlets 230 - 236 written in accordance with the present invention require less code than commands in prior systems. Each executable cmdlet 230 - 236 accepts a corresponding RequestObject 220 - 226 .
  • each executable cmdlet 230 - 236 outputs objects which are input to the next pipelined cmdlet.
  • these objects are input by passing a reference (e.g., handle) to the object.
  • the executable cmdlets 230 - 236 may then perform additional processing on the objects that were passed in.
  • FIG. 3 is one embodiment for a data structure 300 for specifying a grammar for input parameters to a cmdlet.
  • the data structure 300 provides a means for clearly expressing a contract between the reflection-based shell and the cmdlet.
  • the following discussion describes the present invention using the .NET Framework created by Microsoft Corporation of Redmond, Wash. However, other environments may be used without departing from the scope of the present invention.
  • a software developer codes data structure 300 within the code for the corresponding executable cmdlet. The methods and properties that implement this request actually define what input parameters are exposed to the user through the command line.
  • Data structure 300 is a public class that derives from a RequestObject class 304 .
  • the software developer provides a class name 302 for the data structure 300 .
  • the class name 302 identifies the name of the argument specified on the command line for the cmdlet.
  • Each command name 302 represents a verb/noun pair, such as “get/process” and “format/table” in the example command line 200 shown in FIG. 2 .
  • the verb or the noun may be implicit in the command name, such as the “where” command.
  • the class name 302 is not identical to the cmdlet.
  • Data structure 300 includes at least one public member (e.g., Name 330 ).
  • the public members 330 , 332 represent input parameters associated with the cmdlet.
  • Each public member 330 , 332 may have one or more directives in each of the following categories: parsing directive 310 , data validation directive 312 , data generation directive 314 , processing directive 316 , encoding directive 318 , and documentation directive 320 .
  • the directives are surrounded by square brackets and describe the input parameter that follows them. Some of the directives may also be applied at a class level, such as user-interaction type directives.
  • the data structure 300 may also include a private member 340 that the parser recognizes as not an input parameter.
  • the private member 340 may be used for storing data generated based on one of the directives.
  • the name for the public member may be used on the command line to qualify the input parameter on the command line. Otherwise, the public member may be used to store the input parameter based on its position on the command line.
  • the RequestObject is as follows:
  • ParsingParameterPositionAttribute is a parsing directive that describes how to map unqualified parameters based on position.
  • unqualified parameters are parameters that do not use the public member name in association with the input parameter.
  • the following are proper syntaxes after applying the above parsing directives on the “To” and “From” members: $ copy/File-From:a-To:b $ copy/File a b $ copy/File-From:a b $ copy/File a-To:b $ copy/File-To:b-From:a.
  • cmdlet developers are allowed to easily specify a grammar for the input parameters to their cmdlets and perform processing on the input parameters without requiring them to generate any of the underlying logic.
  • the directives are stored in the metadata associated with the cmdlet. As will be described later in conjunction with FIG. 4 , metadata processing is distributed throughout the reflection-based shell. For example, applicability directives, documentation directives, and parsing guideline directives are processed at a very early stage within the parser. Data generation directives and validation directives are processed in the engine once the parser has finished parsing all the input parameters.
  • PrerequisiteMachineRoleAttribute Informs shell whether element is to be used only in certain machine roles (e.g., File Server, Mail Server).
  • PrerequisiteUserRoleAttribute Informs shell whether element is to be used only in certain user roles (e.g., Domain Administrator, Backup Operator).
  • ParsingPromptStringAttribute Specifies a prompt for the parameter. ParsingDefaultAnswerAttribute Specifies default answer for parameter. ParsingDefaultAnswerScriptAttribute Specifies action to get default answer for parameter. ParsingDefaultValueAttribute Specifies default value for parameter. ParsingDefaultValueScriptAttribute Specifies action to get default value for parameter.
  • ValidationRangeAttribute Specifies that parameter must be within certain range.
  • ValidationSetAttribute Specifies that parameter must be within certain collection.
  • ValidationPatternAttribute Specifies that parameter must fit a certain pattern.
  • ValidationLengthAttribute Specifies the strings must be within size range.
  • ValidationTypeAttribute Specifies that parameter must be of certain type.
  • ValidationCountAttributue Specifies that input items must be of a certain number.
  • ValidationFileAttribute Specifies certain properties for a file.
  • ValidationFileAttributesAttribute Specifies certain properties for a file.
  • ValidationFileSizeAttribute Specifies that files must be within specified range.
  • ValidationNetworkAttribute Specifies that given Network Entity supports certain properties.
  • ValidationScriptAttribute Specifies conditions to evaluate before using element.
  • ValidationMethodAttribute Specifies conditions to evaluate before using element.
  • ProcessingTrimStringAttribute Specifies size limit for strings. ProcessingTrimCollectionAttribute Specifies size limit for collection. EncodingTypeCoercionAttribute Specifies Type that objects are to be encoded.
  • each category has a base class that is derived from a basic category class (e.g., CmdAttribute).
  • the basic category class derives from a System.Attribute class.
  • Each category has a pre-defined function (e.g., attrib.func( )) that is called by the parser during category processing.
  • the cmdlet developer may create a custom category that is derived from a custom category class (e.g., CmdCustomAttribute).
  • the cmdlet developer may also extend an existing category class by deriving a directive class from the base category class for that category and override the pre-defined function with their implementation.
  • the cmdlet developer may also override directives and add new directives to the pre-defined set of directives.
  • the order of processing of these directives may be stored in an external data store accessible by the parser.
  • the reflection-based shell looks for registered categories and calls a function (e.g., ProcessCustomDirective) for each of the directives in that category.
  • a function e.g., ProcessCustomDirective
  • the order of category processing may be dynamic by storing the category execution information in a persistent store.
  • the parser checks in the persistent store to determine if any metadata category needs to be executed at that time. This embodiment allows categories to be easily deprecated by removing the category entry from the persistent store.
  • FIG. 4 is a logical flow diagram illustrating a process 400 for handling input parameters entered for a command.
  • the cmdlet has been developed and the metadata has been inserted into the cmdlet source file using the RequestObject shown in FIG. 3 .
  • the cmdlet has been compiled and has been registered.
  • the class name i.e., cmdlet name
  • the process 400 begins at block 401 , where the reflection-based shell has received input (e.g., keystrokes) indicating a cmdlet.
  • the reflection-based shell may recognize the input as a cmdlet by looking up the input from within the registry and associating the typed input with one of the registered cmdlets. Processing proceeds to block 402 .
  • the class associated with the identified cmdlet is identified. This class may also be identified through the registry. Processing continues at block 404 .
  • the metadata includes any of the directives associated with the cmdlet.
  • the directives may apply to the cmdlet itself or to one or more of the parameters specified in the RequestObject.
  • the registration code registers the metadata into a persistent store.
  • the metadata may be stored in an XML file in a serialized format, an external database, and the like.
  • the directives that are specified in the metadata are each associated with a category, such as Applicability Directives, Parsing Guideline Directives, and the like. Each category of directives is processed at a different stage in the reflection-based shell. Each metadata directive handles its own error handling. Processing continues at block 406 .
  • a RequestObject is instantiated based on the identified class. Processing continues at block 408 .
  • reflection is performed on the RequestObject to obtain information regarding the input parameters.
  • the reflection-based shell provides a common interface for returning the reflection data (on a need basis) to the caller.
  • the reflection uses .NET Reflection. Processing continues at block 410 .
  • applicability directives e.g., Table 1
  • the applicability directives insure that the class is used in certain machine roles and/or user roles. For example, certain cmdlets may only be used by Domain Administrators. If the constraint specified in one of the applicability directives is not met, an error occurs. Processing continues at block 412 .
  • Metadata is used to provide intellisense.
  • the entire command line has not yet been entered.
  • the reflection-based shell knows the input parameters that are allowed via reflection on the RequestObject associated with the cmdlet.
  • the reflection-based shell via the engine may auto-complete the input parameter once a disambiguating portion of the input parameter has been typed on the command line. Auto-completion may occur as soon as the portion of the input parameter can identify one of the input parameters unambiguously. Processing continues at block 414 .
  • the process waits until the input parameters for the cmdlet have been entered. Typically, this occurs once the user has indicated the end of the command line, such as by hitting a return key. Processing continues at block 416 .
  • parsing guideline directives are applied and the RequestObject instance is populated with the input parameters.
  • the parser has a set of rules that are used during the parsing.
  • the set of rules specify the manner in which the grammar specified in the RequestObject data structure is converted into the syntax for the input parameters on the command line. For example, given the following RequestObject declaration for the command Foo:
  • command line syntax may be any of the following: $Foo-Name: (string)-Recurse: True $Foo-Name ⁇ string>-Recurse True $Foo/Name (string).
  • the set of rules may be modified by system administrators in order to yield a desired syntax.
  • the parser may support multiple sets of rules, so that more than one syntax can be used by users. Therefore, the grammar specified in the RequestObject structure (e.g., string Name and Bool Recurse) drives the parser.
  • parsing directives describe how the parameters entered on the command line should map to the expected parameters identified in the RequestObject.
  • the following example illustrates parsing directives specifying positional information.
  • Class foo RequestObject ⁇ [ParsingParameterPositionAttribute(0)] String HostName [ParsingParameterPositionAttribute(1)] String AliasName ⁇ .
  • the input parameter types are checked to determine whether correct. If the input parameter types are not correct, the input parameters may be coerced to become correct. If the input parameter types are not correct and can not be coerced, a usage error is printed. The usage error allows the user to become aware of the correct syntax that is expected. The usage error may obtain information describing the syntax from the Documentation Directives 418 . Once the input parameter types have either been mapped or have been verified, the corresponding members in the RequestObject instance are populated. Processing continues at decision block 420 .
  • the reflection-based shell interacts with the user to obtain the input parameters. Developers may specify that input parameters be obtained through user interaction by specifying a CmdPgRequireInteraction directive for the parameter in the RequestObject.
  • the reflection-based shell may determine that user interaction is needed if not all the input parameters are entered on the command line. As long as the input parameter, the cmdlet itself, and other settings do not disallow interaction, the reflection-based shell will interact with the user to obtain the necessary input parameter.
  • a flag may be used to specify whether user interaction is allowed at the user level, group level, and enterprise-level. If one of the levels does not allow user interaction, an error message is issued. Once the user interaction has been performed, processing continues at block 424 .
  • the engine performs another pass on the RequestObject instance and applies any remaining directives to the input parameters.
  • the remaining directives include data generation directives, data validation directives, object processing directives, and object encoding directives. These directives are processed in the engine once the parser has finished parsing the input parameters. A representative directive from each of the categories shown above in Tables 3-5 will now be described.
  • the first representative directive is from the data generation directive.
  • the RequestObject may contain the following statements: [ParsingDefaultAnswerScriptAttribute (Filename, F)] String Name; private Arraylist F;.
  • the parser does not treat this declaration as an input parameter to the cmdlet. Instead, the Arraylist F is temporary storage for the data that is generated by the service specified in the Data Generation directive.
  • the service is “Filename”.
  • Filename may be a utility provided by the reflection-based framework or may be a third party function or utility.
  • the engine identifies a service named “Filename” within the registry. The registration of the service occurs during installation of the service.
  • the Data Generation directive allows unique processing to occur on input parameters. For example, the service could perform wildcard expansion on a filename entered as “A*” on the command line. Before the second pass, the Name member contains “A*” as it was entered on the command line.
  • the Filename service may locate a set of files starting with A and store them in the Arraylist F.
  • the Data Generation directive may provide wildcarding expansion of filenames, but can also perform wildcard expansion of usernames, processes, and the like.
  • the Data Generation directive may perform other processing on the input parameters.
  • An exemplary data validation directive may include the following statements within the RequestObject: [ValidationSetAttribute (“Debug”, “Production”, “Test”)] [ParsingParameterMandatoryAttribute] String Name;.
  • the parser recognizes that Name is a mandatory input parameter and the string must either be Debug, Production, or Test. Otherwise, the data validation directive will issue an error.
  • the error may use documentation directives for supplying the error message.
  • An exemplary object processing directive may include the following statements within the RequestObject: [tolower] String HostName;.
  • the argument specified for the HostName is converted to a lower case string before handing the RequestObject to the executable cmdlet.
  • An exemplary object encoding directive may include the following statements within the RequestObject: [TOIP (HostIP)] String HostName; Private IPaddr HostIP;.
  • the string that was input as the HostName is converted to an IP address.
  • the parser does not treat the HostIP parameter as an input parameter because it is declared as Private.
  • the executable cmdlet may reference the HostIP member.
  • the above object encoding directive may not appear to save many lines of code, in reality, the directive reduces the amount of code written by third party developers quite substantially. For example, in prior environments, a third party developer handles error processing.
  • the error message is a string, the string may need to be converted into multiple languages.
  • the present invention provides uniform error handling.
  • the present invention provides a mechanism for uniformly converting the error message to multiple languages. Processing continues at block 426 .
  • the RequestObject instance is passed to the executable cmdlet.
  • the executable cmdlet will then use these input parameter in its processing.
  • the cmdlet of the present invention does not have to write any unique code to parse or validate input parameters.
  • the present invention provides an even richer environment in which a software developer may specify additional processing of the input parameters via directives.
  • Each directive handles its own error messages. If an error message needs to be displayed, the directive gets the localized string from a document store and calls the display interface to display the error message. Data related to documentation directives may be stored in the cmdlet, in an XML store or external database, or in resource files. Thus, the present invention can provide consistent error messages for all cmdlets and reduces the localization effort of third parties.
  • the reflection-based shell provides a common interface that returns data generated by one directive in a form of an object to the calling directive.
  • the calling directive is responsible for casting the data to the required datatype. While Tables 1-5 illustrate representative directives for several categories, other directives may be added and additional categories may be added without departing from the scope of the present invention.
  • the present invention provides a mechanism for defining a grammar for input parameters to a cmdlet.
  • the mechanism allows the developers to develop, test, and support cmdlets.
  • the cmdlet has fewer lines of code, is faster to implement, has fewer defects, and has easier-to-address defects.
  • the mechanism provides more consistency in syntax, semantics, error handling, resource management, security, and the like.
  • the parsable data that is parsed may be obtained through voice, a graphical user-interface, a script or the like without departing from the scope of the present invention.
  • the present invention may be used to describe a rich set of grammars by allowing one RequestObject class to declare another RequestObject class.
  • the present invention provides great versatility to system administrators.

Abstract

The present invention is directed at a reflection-based shell that provides reflection-based processing of input parameters for a command. The reflection-based processing includes parsing, data generation, data validation, object encoding, object processing, documentation, and the like. The reflection-based shell provides a mechanism for specifying a grammar for the input parameters using a class. The method includes receiving a parsable stream that includes a command and at least one parameter. Retrieving definitional information that describes an expected parameter for the command. Using the definitional information to create an object for storing the at least one parameter in a format in accordance with the description of the expected parameters. Passing the object to the command.

Description

BACKGROUND OF THE INVENTION
System administration of multi-user computer systems is very specialized. The system administrators who are responsible for system administration are expected to know and understand commands that use inconsistent syntaxes, error reporting, and the like. These inconsistencies between the commands occur because the commands are written by several different software developers, each using their own style. The inconsistencies cause difficulties for the system administrators.
One difficulty relates to the usability of the commands. Having inconsistent commands makes system administration more difficult to learn and use. For example, some developers may prefer to use dashes (“-”) between parameters, others may prefer forward slashes (“/”), and still others may prefer to use another unique syntax. The developers may each have their own style in reporting error messages too. Thus, the system administrator must know the syntax for each command and learn the format of each error message.
Another difficulty relates to the maintenance of the commands. For example, when the developer who wrote one of the commands leaves, someone else must discover the logic that was used. In order to discover the logic, the other developer must look at the code itself or look at documentation about the command. Neither of these methods is very desirable.
Prior attempts at making commands more consistent have focused on providing a library of routines that perform common functionality. While this library may decrease the amount of code used for performing common functionality provided by the library routines, the developers still use their own style in handling error conditions that arise from using any of the library routines. In addition, the use of the library does not affect the need for each command to contain logic for obtaining input parameters from the command line. Therefore, while using a library of routines may decrease some of the code that needs to be written, there is still a considerable amount of duplicative code that is generated for each command in order to perform parsing, data validation, and error reporting.
Therefore, there is a need for an environment in which input parameters to commands are obtained and processed in a more consistent manner while reducing the amount of code that is required for the command as well as providing consistent error messages during the parameter acquisition phase for all commands.
SUMMARY OF THE INVENTION
The present invention is directed at a reflection-based shell that provides reflection-based processing of input parameters for a command. The reflection-based processing includes parsing, data generation, data validation, object encoding, object processing, documentation, and the like. The reflection-based shell provides a mechanism for specifying a grammar for the input parameters using a class. Third party developers use the class to specify a grammar for their commands. In operation, the present invention receives a parsable stream. The parsable stream may be obtained from a command line, voice input, a script, and the like. The parsable stream includes a command and at least one parameter. Based on the parsable stream, definitional information that describes an expected parameter for the command is retrieved. Using the definitional information, an object is created (i.e., an instance of the class created by the developer). The object stores the at least one parameter in a format in accordance with the description of the expected parameter. The object is then passed to the command, which does its unique processing. The definitional information may include directives that specify actions to be performed on the parsable stream, such as how to map the parameters to the expected parameter, how to obtain the parameters (e.g., interactive), and the like. The directives may also include actions related to parsing, validation, documentation, data generation, and data processing.
Thus, one advantage of the present invention is that command developers may easily specify a grammar for the input parameters to their command without needing to write the logic that parses the command line to get the input parameters or that validates the input parameters. In so doing, the present invention reduces the amount of code developers need to write and allows the syntax for commands to be more consistent, yet quite versatile.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an exemplary computing device that may be used in one exemplary embodiment of the present invention.
FIG. 2 is a functional flow diagram illustrating the processing of a command line through a parser and an engine within a reflection-based shell in accordance with the present invention.
FIG. 3 is one embodiment for a data structure for specifying a grammar for input parameters for a command in accordance with the present invention.
FIG. 4 is a logical flow diagram illustrating an exemplary process for handling input parameters entered on the command line within the reflection-based shell of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Briefly stated, the present invention is directed at a reflection-based shell that provides reflection-based processing of input parameters for a command. As will become apparent after reading the following detailed description, the present invention minimizes the amount of code that third party developers need to write and minimizes the amount of knowledge that system administrators need to know in order to perform system administrative tasks. Therefore, the present invention significantly reduces system administrative tasks. In addition, the present invention provides a more consistent syntax for input parameters, and provides common functionality for the processing associated with the input parameters.
FIG. 1 illustrates an exemplary computing device that may be used in one exemplary embodiment of the present invention. In a very basic configuration, computing device 100 typically includes at least one processing unit 102 and system memory 104. Depending on the exact configuration and type of computing device, system memory 104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory 104 typically includes an operating system 105, one or more program modules 106, and may include program data 107. The operating system 105 includes a command processor 130 that executes operating system commands. The command processor 130 includes a shell 131 (i.e., the command processor interface) that accepts the operating system commands. The shell may display a command prompt, may display a graphical user interface, or any other means for inputting and interpreting user input. The shell 131 verifies that the entered commands are valid and sends the verified commands onto another part of the command processor 130 for execution. This basic configuration is illustrated in FIG. 1 by those components within dashed line 108.
Computing device 100 may have additional features or functionality. For example, computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in FIG. 1 by removable storage 109 and non-removable storage 110. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory 104, removable storage 109 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 100. Any such computer storage media may be part of device 100. Computing device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 114 such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.
Computing device 100 may also contain communication connections 116 that allow the device to communicate with other computing devices 118, such as over a network. Communication connections 116 is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
FIG. 2 is a functional flow diagram illustrating the processing of a command line 250 through a parser 202 and an engine 204 within a reflection-based shell 200 in accordance with the present invention. The exemplary command line 250 pipelines several commands (i.e., process command 260, where command 262, sort command 264, and table command 266). However, the following discussion focuses on the reflection-based processing of input parameters for one command (e.g., where command 262). The reflection-based processing for the other commands is performed in a similar fashion. The command line 250 may pass input parameters to any of the commands (e.g., “handlecount>400” is passed to the where command 262). One will note that the process command 260 does not have any associated input parameters. In the past, each command was responsible for parsing the input parameters associated with the command, determining whether the input parameters were valid, and issuing error messages if the input parameters were not valid. Because the commands were typically written by various program the syntax for the input parameters on the command line were not very consistent. In addition, if an error occurred, the error messages, even for the same error, were not very consistent between the commands.
For example, in a Unix environment, a “ls” command and a “ps” command have many inconsistencies between them. While both accept an option “-w”, the “-w” option is used by the “ls” command to denote the width of the page, while the “-w” option is used by the “ps” command to denote print wide output (in essence, ignoring page width). The help pages associated with the “ls” and the “ps” command have several inconsistencies too, such as having options bolded in one and not the other, sorting options alphabetically in one and not the other, requiring some options to have dashes and some not.
As will be described in detail below, the present invention provides a more consistent approach and minimizes the amount of duplicative code that each developer must write. The reflection-based shell 200 provides a syntax (e.g., grammar), a corresponding semantics (e.g., a dictionary), and a reference model to enable developers to easily take advantage of common functionality provided by the reflection-based shell 200.
Before describing the present invention any further, definitions for terms appearing through-out this specification are provided. A “command” refers to a stand-alone executable program. A “commandlet” or “cmdlet” refers to programs that are considerably smaller than commands. In one embodiment, each cmdlet defines a noun-verb pair (e.g., get/process in command line 250). The following discussion uses the term cmdlet when referring to a command written in accordance with the present invention. However, in some instances, the more common term “command” may be used to refer to cmdlet. Input parameter refers to input-fields for a cmdlet. Argument refers to an input parameter passed to a command or cmdlet that is the equivalent of a single string in the argv array or passed as a single element in a RequestObject. As will be described below, a RequestObject refers to a mechanism for specifying a grammar for the cmdlet. An argument is one of an option, an option-argument, or an operand following the command-name. Examples of arguments are given based on the following command line:
findstr/i/d:\winnt;\winnt\system32 aa*b *.ini.
In the above command line, “findstr” is argument 0, “/i” is argument 1, “/d:\winnt;\winnt\system32” is argument 2, “aa*b” is argument 3, and “*.ini” is argument 4. An “option” is an argument to a command or cmdlet that is generally used to specify changes to the program's default behavior. Continuing with the example command line above, “/i” and “/d” are options. An “option-argument” is an input parameter that follows certain options. In some cases, an option-argument is included within the same argument string as the option. In other cases, the option-argument is included as the next argument. Referring again to the above command line, “winnt;\winnt\system32” is an option-argument. An “operand” is an argument to a command or cmdlet that is generally used as an object supplying information to a program necessary to complete program processing. Operands generally follow the options in a command line. Referring to the example command line above again, “aa*b” and “*.ini” are operands. A “parsable stream” includes the arguments.
“Class members” refers to elements, such as sub-classes, fields, constants, methods, structures, properties, arrays, indexers, interfaces, events, exceptions, and the like. A “directive” refers to a metadata attribute. A “category” refers to a set of particular types of directives. As will be explained in detail below, the reflection-based shell of the present invention provides several categories of directives, such as parsing directives, data generation directives, and the like. Within each category, the reflection-based shell provides several directives. The categories and the directives may be extended by the software developers.
Referring to FIG. 2, parser 202 parses a parsable stream (e.g., command line 250) into RequestObjects 220-226 (e.g., where request 222). Each RequestObject 220-226 is associated with one of the cmdlets 260-266. Briefly, described in detail below in conjunction with FIG. 3, the RequestObjects 220-226 provide a means or mechanism for a developer to specify a grammar for the input parameters to the cmdlet. The RequestObject is passed to the corresponding cmdlet executable (e.g., where executable 232). However, as will be described below in conjunction with FIG. 4, parser 202 and engine 204 performs various processing on the input parameters specified on the command line 200 before passing the RequestObject to the cmdlet executable. The processing includes parsing, parameter validation, data generation, parameter processing, parameter encoding, and parameter documentation. Because parser 202 and engine 204 perform common functionality on the input parameters on the command line, the reflection-based shell 200 is able to issue consistent error messages to users. As one will recognize, the executable cmdlets 230-236 written in accordance with the present invention require less code than commands in prior systems. Each executable cmdlet 230-236 accepts a corresponding RequestObject 220-226. In addition, each executable cmdlet 230-236 outputs objects which are input to the next pipelined cmdlet. Typically, these objects are input by passing a reference (e.g., handle) to the object. The executable cmdlets 230-236 may then perform additional processing on the objects that were passed in.
FIG. 3 is one embodiment for a data structure 300 for specifying a grammar for input parameters to a cmdlet. In essence, the data structure 300 provides a means for clearly expressing a contract between the reflection-based shell and the cmdlet. The following discussion describes the present invention using the .NET Framework created by Microsoft Corporation of Redmond, Wash. However, other environments may be used without departing from the scope of the present invention.
A software developer codes data structure 300 within the code for the corresponding executable cmdlet. The methods and properties that implement this request actually define what input parameters are exposed to the user through the command line. Data structure 300 is a public class that derives from a RequestObject class 304. The software developer provides a class name 302 for the data structure 300. The class name 302 identifies the name of the argument specified on the command line for the cmdlet. Each command name 302 represents a verb/noun pair, such as “get/process” and “format/table” in the example command line 200 shown in FIG. 2. The verb or the noun may be implicit in the command name, such as the “where” command. One will note that, in one embodiment, the class name 302 is not identical to the cmdlet. In this embodiment, other annotation is used to identify the name of the cmdlet. Data structure 300 includes at least one public member (e.g., Name 330). The public members 330, 332 represent input parameters associated with the cmdlet. Each public member 330, 332 may have one or more directives in each of the following categories: parsing directive 310, data validation directive 312, data generation directive 314, processing directive 316, encoding directive 318, and documentation directive 320. The directives are surrounded by square brackets and describe the input parameter that follows them. Some of the directives may also be applied at a class level, such as user-interaction type directives. The data structure 300 may also include a private member 340 that the parser recognizes as not an input parameter. The private member 340 may be used for storing data generated based on one of the directives.
The name for the public member may be used on the command line to qualify the input parameter on the command line. Otherwise, the public member may be used to store the input parameter based on its position on the command line. The following is an example that illustrates this concept, the RequestObject is as follows:
public class FileCopyRequest : RequestObject
{
[ParsingParameterPositionAttribute(0)]
public string From;
[ParsingParameterPositionAttribute (1)]
public string To;
...
}.
ParsingParameterPositionAttributeis a parsing directive that describes how to map unqualified parameters based on position. As mentioned above, unqualified parameters are parameters that do not use the public member name in association with the input parameter. The following are proper syntaxes after applying the above parsing directives on the “To” and “From” members:
$ copy/File-From:a-To:b
$ copy/File a b
$ copy/File-From:a b
$ copy/File a-To:b
$ copy/File-To:b-From:a.
The following syntax would be invalid:
$ copy/File-To:b a.
$ copy/File b-From:a
As will be described below, other directives affect the processing of the input parameter specified on the command line. Thus, through the use of directives, cmdlet developers are allowed to easily specify a grammar for the input parameters to their cmdlets and perform processing on the input parameters without requiring them to generate any of the underlying logic.
The directives are stored in the metadata associated with the cmdlet. As will be described later in conjunction with FIG. 4, metadata processing is distributed throughout the reflection-based shell. For example, applicability directives, documentation directives, and parsing guideline directives are processed at a very early stage within the parser. Data generation directives and validation directives are processed in the engine once the parser has finished parsing all the input parameters.
The following tables illustrate representative directives for the various categories, along with an explanation of the processing performed by the reflection-based shell in response to the directive.
TABLE 1
Applicability Directives
Name Description
PrerequisiteMachineRoleAttribute Informs shell whether element is
to be used only in certain machine
roles (e.g., File Server, Mail Server).
PrerequisiteUserRoleAttribute Informs shell whether element is to
be used only in certain user roles
(e.g., Domain Administrator,
Backup Operator).
TABLE 2
Parsing Guideline Directives
Name Description
ParsingParameterPositionAttribute Maps unqualified parameters based on
position.
ParsingVariableLengthParameterListAttribute Maps parameters not having a Parsing
ParameterPosition attribute.
ParsingDisallowInteractionAttribute Specifies action when number of
parameters is less than required
number.
ParsingRequireInteractionAttribute Specifies that parameters are obtained
through interaction.
ParsingHiddenElementAttribute Makes parameter invisible to end user.
ParsingMandatoryParameterAttribute Specifies that the parameter is required.
ParsingPasswordParameterAttribute Requires special handling of parameter.
ParsingPromptStringAttribute Specifies a prompt for the parameter.
ParsingDefaultAnswerAttribute Specifies default answer for parameter.
ParsingDefaultAnswerScriptAttribute Specifies action to get default answer
for parameter.
ParsingDefaultValueAttribute Specifies default value for parameter.
ParsingDefaultValueScriptAttribute Specifies action to get default value for
parameter.
Documentation Directives
Name Description
DocumentNameAttribute Provides a Name to refer to
elements for interaction or help.
DocumentShortDescriptionAttribute Provides brief description of
element.
DocumentLongDescriptionAttribute Provides detailed description of
element.
DocumentExampleAttribute Provides example of element.
DocumentSeeAlsoAttribute Provides a list of related elements.
DocumentSynopsisAttribute Provides documentation
information for element.
TABLE 4
Data Validation Directives
Name Description
ValidationRangeAttribute Specifies that parameter must be within certain range.
ValidationSetAttribute Specifies that parameter must be within certain collection.
ValidationPatternAttribute Specifies that parameter must fit a certain pattern.
ValidationLengthAttribute Specifies the strings must be within size range.
ValidationTypeAttribute Specifies that parameter must be of certain type.
ValidationCountAttributue Specifies that input items must be of a certain number.
ValidationFileAttribute Specifies certain properties for a file.
ValidationFileAttributesAttribute Specifies certain properties for a file.
ValidationFileSizeAttribute Specifies that files must be within specified range.
ValidationNetworkAttribute Specifies that given Network Entity supports certain properties.
ValidationScriptAttribute Specifies conditions to evaluate before using element.
ValidationMethodAttribute Specifies conditions to evaluate before using element.
TABLE 5
Processing and Encoding Directives
Name Description
ProcessingTrimStringAttribute Specifies size limit for strings.
ProcessingTrimCollectionAttribute Specifies size limit for collection.
EncodingTypeCoercionAttribute Specifies Type that objects are to be
encoded.
In the embodiment using the .NET Framework, each category has a base class that is derived from a basic category class (e.g., CmdAttribute). The basic category class derives from a System.Attribute class. Each category has a pre-defined function (e.g., attrib.func( )) that is called by the parser during category processing. The cmdlet developer may create a custom category that is derived from a custom category class (e.g., CmdCustomAttribute). The cmdlet developer may also extend an existing category class by deriving a directive class from the base category class for that category and override the pre-defined function with their implementation. The cmdlet developer may also override directives and add new directives to the pre-defined set of directives.
The order of processing of these directives may be stored in an external data store accessible by the parser. The reflection-based shell looks for registered categories and calls a function (e.g., ProcessCustomDirective) for each of the directives in that category. Thus, the order of category processing may be dynamic by storing the category execution information in a persistent store. At different processing stages, the parser checks in the persistent store to determine if any metadata category needs to be executed at that time. This embodiment allows categories to be easily deprecated by removing the category entry from the persistent store.
FIG. 4 is a logical flow diagram illustrating a process 400 for handling input parameters entered for a command. At this point, the cmdlet has been developed and the metadata has been inserted into the cmdlet source file using the RequestObject shown in FIG. 3. The cmdlet has been compiled and has been registered. During registration, the class name (i.e., cmdlet name) was written in the registration store. The process 400 begins at block 401, where the reflection-based shell has received input (e.g., keystrokes) indicating a cmdlet. The reflection-based shell may recognize the input as a cmdlet by looking up the input from within the registry and associating the typed input with one of the registered cmdlets. Processing proceeds to block 402.
At block 402, the class associated with the identified cmdlet is identified. This class may also be identified through the registry. Processing continues at block 404.
At block 404, metadata associated with the class is read. The metadata includes any of the directives associated with the cmdlet. The directives may apply to the cmdlet itself or to one or more of the parameters specified in the RequestObject. During cmdlet registration, the registration code registers the metadata into a persistent store. The metadata may be stored in an XML file in a serialized format, an external database, and the like. As shown in the Tables above, the directives that are specified in the metadata are each associated with a category, such as Applicability Directives, Parsing Guideline Directives, and the like. Each category of directives is processed at a different stage in the reflection-based shell. Each metadata directive handles its own error handling. Processing continues at block 406.
At block 406, a RequestObject is instantiated based on the identified class. Processing continues at block 408.
At block 408, reflection is performed on the RequestObject to obtain information regarding the input parameters. The reflection-based shell provides a common interface for returning the reflection data (on a need basis) to the caller. In the embodiment described above, the reflection uses .NET Reflection. Processing continues at block 410.
At block 410, applicability directives (e.g., Table 1) are applied. The applicability directives insure that the class is used in certain machine roles and/or user roles. For example, certain cmdlets may only be used by Domain Administrators. If the constraint specified in one of the applicability directives is not met, an error occurs. Processing continues at block 412.
At block 412, metadata is used to provide intellisense. At this point in processing, the entire command line has not yet been entered. The reflection-based shell, however, knows the input parameters that are allowed via reflection on the RequestObject associated with the cmdlet. Thus, the reflection-based shell via the engine may auto-complete the input parameter once a disambiguating portion of the input parameter has been typed on the command line. Auto-completion may occur as soon as the portion of the input parameter can identify one of the input parameters unambiguously. Processing continues at block 414.
At block 414, the process waits until the input parameters for the cmdlet have been entered. Typically, this occurs once the user has indicated the end of the command line, such as by hitting a return key. Processing continues at block 416.
At block 416, parsing guideline directives are applied and the RequestObject instance is populated with the input parameters. The parser has a set of rules that are used during the parsing. The set of rules specify the manner in which the grammar specified in the RequestObject data structure is converted into the syntax for the input parameters on the command line. For example, given the following RequestObject declaration for the command Foo:
class Foo : RequestObject
{
string Name;
Bool Recurse;
}
the command line syntax may be any of the following:
$Foo-Name: (string)-Recurse: True
$Foo-Name <string>-Recurse True
$Foo/Name (string).
The set of rules may be modified by system administrators in order to yield a desired syntax. In addition, the parser may support multiple sets of rules, so that more than one syntax can be used by users. Therefore, the grammar specified in the RequestObject structure (e.g., string Name and Bool Recurse) drives the parser.
In general, the parsing directives describe how the parameters entered on the command line should map to the expected parameters identified in the RequestObject. The following example illustrates parsing directives specifying positional information.
Class foo : RequestObject
{
[ParsingParameterPositionAttribute(0)]
String HostName
[ParsingParameterPositionAttribute(1)]
String AliasName
}.
The input parameter types are checked to determine whether correct. If the input parameter types are not correct, the input parameters may be coerced to become correct. If the input parameter types are not correct and can not be coerced, a usage error is printed. The usage error allows the user to become aware of the correct syntax that is expected. The usage error may obtain information describing the syntax from the Documentation Directives 418. Once the input parameter types have either been mapped or have been verified, the corresponding members in the RequestObject instance are populated. Processing continues at decision block 420.
At decision block 420, a determination is made whether any of the input parameters need interaction with the user. If any of the parameters need user interaction, the process proceeds to block 422. Otherwise processing continues at block 424.
At block 422, the reflection-based shell interacts with the user to obtain the input parameters. Developers may specify that input parameters be obtained through user interaction by specifying a CmdPgRequireInteraction directive for the parameter in the RequestObject. In addition, the reflection-based shell may determine that user interaction is needed if not all the input parameters are entered on the command line. As long as the input parameter, the cmdlet itself, and other settings do not disallow interaction, the reflection-based shell will interact with the user to obtain the necessary input parameter. A flag may be used to specify whether user interaction is allowed at the user level, group level, and enterprise-level. If one of the levels does not allow user interaction, an error message is issued. Once the user interaction has been performed, processing continues at block 424.
At block 424, the engine performs another pass on the RequestObject instance and applies any remaining directives to the input parameters. The remaining directives include data generation directives, data validation directives, object processing directives, and object encoding directives. These directives are processed in the engine once the parser has finished parsing the input parameters. A representative directive from each of the categories shown above in Tables 3-5 will now be described.
The first representative directive is from the data generation directive. The RequestObject may contain the following statements:
[ParsingDefaultAnswerScriptAttribute (Filename, F)]
String Name;
private Arraylist F;.
Because the Arraylist F is private, the parser does not treat this declaration as an input parameter to the cmdlet. Instead, the Arraylist F is temporary storage for the data that is generated by the service specified in the Data Generation directive. In the above example, the service is “Filename”. Filename may be a utility provided by the reflection-based framework or may be a third party function or utility. When the engine encounters the above directive, the engine identifies a service named “Filename” within the registry. The registration of the service occurs during installation of the service. The Data Generation directive allows unique processing to occur on input parameters. For example, the service could perform wildcard expansion on a filename entered as “A*” on the command line. Before the second pass, the Name member contains “A*” as it was entered on the command line. During the second pass, the Filename service may locate a set of files starting with A and store them in the Arraylist F. As one skilled in the art will appreciate, not only will the Data Generation directive provide wildcarding expansion of filenames, but can also perform wildcard expansion of usernames, processes, and the like. In addition, the Data Generation directive may perform other processing on the input parameters.
An exemplary data validation directive may include the following statements within the RequestObject:
[ValidationSetAttribute (“Debug”, “Production”, “Test”)]
[ParsingParameterMandatoryAttribute]
String Name;.
Given the above data validation directives, the parser recognizes that Name is a mandatory input parameter and the string must either be Debug, Production, or Test. Otherwise, the data validation directive will issue an error. The error may use documentation directives for supplying the error message.
An exemplary object processing directive may include the following statements within the RequestObject:
[tolower]
String HostName;.
Given the above object processing directive, the argument specified for the HostName is converted to a lower case string before handing the RequestObject to the executable cmdlet.
An exemplary object encoding directive may include the following statements within the RequestObject:
[TOIP (HostIP)]
String HostName;
Private IPaddr HostIP;.
Given the above object encoding directive, the string that was input as the HostName is converted to an IP address. The parser does not treat the HostIP parameter as an input parameter because it is declared as Private. However, the executable cmdlet may reference the HostIP member. While the above object encoding directive may not appear to save many lines of code, in reality, the directive reduces the amount of code written by third party developers quite substantially. For example, in prior environments, a third party developer handles error processing. In addition, if the error message is a string, the string may need to be converted into multiple languages. However, the present invention provides uniform error handling. In addition, the present invention provides a mechanism for uniformly converting the error message to multiple languages. Processing continues at block 426.
At block 426, the RequestObject instance is passed to the executable cmdlet. The executable cmdlet will then use these input parameter in its processing. Thus, contrary to prior command implementations, the cmdlet of the present invention does not have to write any unique code to parse or validate input parameters. In addition, the present invention provides an even richer environment in which a software developer may specify additional processing of the input parameters via directives.
Each directive handles its own error messages. If an error message needs to be displayed, the directive gets the localized string from a document store and calls the display interface to display the error message. Data related to documentation directives may be stored in the cmdlet, in an XML store or external database, or in resource files. Thus, the present invention can provide consistent error messages for all cmdlets and reduces the localization effort of third parties.
In addition, the reflection-based shell provides a common interface that returns data generated by one directive in a form of an object to the calling directive. The calling directive is responsible for casting the data to the required datatype. While Tables 1-5 illustrate representative directives for several categories, other directives may be added and additional categories may be added without departing from the scope of the present invention.
Thus, as described above, the present invention provides a mechanism for defining a grammar for input parameters to a cmdlet. The mechanism allows the developers to develop, test, and support cmdlets. The cmdlet has fewer lines of code, is faster to implement, has fewer defects, and has easier-to-address defects. The mechanism provides more consistency in syntax, semantics, error handling, resource management, security, and the like. The above discussion described the present invention within a .NET framework. However, those skilled in the art will appreciate that the present invention may be implemented within any operating system that provides reflection capabilities. In addition, the present invention is described in a command-line embodiment. However, the parsable data that is parsed may be obtained through voice, a graphical user-interface, a script or the like without departing from the scope of the present invention. In addition, the present invention may be used to describe a rich set of grammars by allowing one RequestObject class to declare another RequestObject class. Thus, the present invention provides great versatility to system administrators.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (24)

1. A computer-readable storage media having computer executable instructions, the instructions, when executed, performing a method comprising:
receiving a parsable stream that includes an identifier associated with a command;
retrieving definitional information based on the identifier that describes an expected parameter for the command;
creating an object based on the definitional information;
storing a parameter obtained from the parsable stream in the object in accordance with the definitional information associated with the expected parameter;
applying a plurality of directives to the parsable stream, the plurality of directives comprising:
a processing directive configured to manipulate the parameter before providing the object with the parameter to the command and includes specific size limits for strings and for collections that can be processed;
a documentation directive that, when requested, generates textual information about the parameter and provides a description of correct syntax when an invalid syntax is encountered;
an interaction directive that determines a user interface for input of the expected parameter, wherein the interaction directive is applied if the expected parameter is not received in the parsable stream; and
providing the object to the command, the object having a method invocable by the command, wherein:
the definitional information and the plurality of directives are either derived from a reflection-based shell or extended by a developer of the command;
the reflection-based shell provides one or more categories of directives and one or more directives under each category of directives; and
the definition information and the plurality of directives associated with a first command are different from the definition information and the plurality of directives associated with a second command.
2. A computer-readable storage media of claim 1, wherein the parsable stream is entered on a command line.
3. A computer-readable storage media of claim 1, wherein the parsable stream is generated via voice input.
4. A computer-readable storage media of claim 1, wherein the parsable stream is generated programmatically.
5. A computer-readable storage media of claim 1, further providing intellisense as the parsable stream is being generated to autocomplete the parsable stream based on the definitional information, wherein the autocomplete occurs upon receiving a disambiguating portion of the parseable stream.
6. A computer-readable storage media of claim 1, the method further comprising:
applying a parsing directive that correlates the parameter to the expected parameter associated with the object, the parsing directive being associated with the definitional information, wherein the parsing directive correlates based on a set of rules which specify a manner in which the grammar of the object is converted to a syntax of the parameter received in the parsable stream;
verifying the syntax of the parameter;
correcting the syntax of the parameter based on syntax information from the documentation directive; and
populating the object with the parameters.
7. A computer-readable storage media of claim 1, the method further comprising:
applying a parsing directive that determines a manner for obtaining the parameter, including requesting the parameter from a user, the parsing directive being associated with the definitional information:
determining the parsable stream does not include a necessary parameter required for the object;
indicating the necessary parameter is needed by displaying a flag, wherein the flag indicates a permissible level of user interaction to supply the necessary parameter, the level of user interaction includes, user level, group level and enterprise level;
requesting the necessary parameter from the user.
8. A computer-readable storage media of claim 1, the method further comprising:
applying a data validation directive to determine whether the parsable stream meets a criterion specified by the data validation directive associated with the definitional information; and
in response to applying the data validation directive, generating an validation error message, wherein the validation error message includes information from the documentation directive.
9. A computer-readable storage media of claim 1, the method further comprising applying a data generation directive on the parameter to generate a set of information that is stored in the object, the data generation directive being associated with the definitional information, wherein the data generation directive provides wildcard expansion of one or more of: filenames, usernames and processes.
10. A computer-readable storage media of claim 1, further comprising applying a second processing directive on the parameter to manipulate the parameter before providing the object with the parameter to the command, the processing directive being associated with the definitional information including specific type that objects are to be encoded.
11. A computer-readable storage media encoded with a data structure for specifying a grammar for input parameters using a class, the data structure comprising:
a class name for the class of an object, the class name identifying a command specified by a developer;
definitional information of an expected parameter associated with the command, wherein the expected parameter is part of a parsable stream that includes an identifier associated with the command definitional information defining a grammar for the command; and
a plurality of directives associated with the class, comprising:
an interaction directive that determines a user interface for input of the expected parameter if the expected parameter is not entered at a command line;
a document directive, that specifies textual information on the expected parameter when textual information on the expected parameter is requested, the textual information including a name to refer to an element in a command and a description of the elements; and
a documentation directive that, when requested, generates textual information about the parameter, and provides a description of correct syntax when an invalid syntax is encountered, wherein:
the class is derived from a base class, the base class comprising a plurality of categories of directives and one or more directives under each category of directives; and
the plurality of directives of the class are either derived from the corresponding category of directives of the base class or extended by the developer of the command for the class.
12. A computer-readable storage media of claim 11, wherein the definitional information includes a member name for a member of the object, the member name corresponds to a qualifier for the expected parameter, the qualifier being optionally supplied with the expected parameter when the command is invoked.
13. A computer-readable storage media of claim 11, wherein the definitional information includes a datatype, the datatype specifies a data format for the expected parameter.
14. A computer-readable storage media of claim 11, wherein the plurality of directives further includes a parsing directive that specifies a rule for mapping the expected parameter to the definitional information.
15. A computer-readable storage media of claim 11, wherein the plurality of directives further includes a data validation directive that specifies a validation process that is performed on the expected parameter.
16. A computer-readable storage media of claim 11, wherein the plurality of directives further includes a data generation directive that specifies a service that is called to generate a set of data based on the expected parameter, the data generation directive allowing unique processing to occur on input parameters.
17. A computer-readable storage media of claim 11, wherein the plurality of directives further includes a directive that specifies additional processing performed on the expected parameter.
18. A computer-readable storage media of claim 11, wherein the description of the correct syntax being stored in an Extensible Markup Language (XML) store.
19. A computer-readable storage media of claim 11, wherein the definition information and the plurality of directives associated with a first command are different from the definition information and the plurality of directives associated with a second command.
20. A system that performs reflection-based processing on parameters input to a command, the system comprising:
a processor; and
a memory, the memory being allocated for a plurality of computer-executable instructions which are loaded into the memory for execution by the processor, the computer-executable instructions performing a method comprising:
receiving a parsable stream that includes an identifier associated with the command;
retrieving definitional information based on the identifier that describes an expected parameter for the command, wherein the definitional information includes specific size limits for strings and for collections that can be processed;
creating an object based on the definitional information;
storing a parameter obtained from the parsable stream in the object in accordance with the definitional information associated with the expected parameter;
applying a plurality of directives to the parsable stream, the plurality of directives comprising:
a processing directive configured to manipulate the parameter before providing the object with the parameter to the command;
a documentation directive that, when requested, generates textual information about the parameter, and provides a description of correct syntax when an invalid syntax is encountered;
an interaction directive that determines a user interface for input of the expected parameter, wherein the interaction directive is applied if the expected parameter is not received in the parsable stream; and
providing the object to the command, the object having a method invocable by the command, wherein:
the definitional information and the plurality of directives are either derived from a reflection-based shell or extended by a developer of the command;
the reflection-based shell provides one or more categories of directives and one or more directives under each category of directives; and
the definition information and the plurality of directives associated with a first command are different from the definition information and the plurality of directives associated with a second command.
21. The system of claim 20, wherein the parsable stream is entered on a command line.
22. The system of claim 20, wherein retrieving definitional information includes identifying a class associated with the command.
23. The system of claim 22, wherein retrieving definitional information further includes reading metadata from the class.
24. The system of claim 20, wherein the computer-executable instructions further comprises applying a directive to the parameter that performs processing on the parameter in accordance with the directive associated with the definitional information.
US10/438,234 2003-05-12 2003-05-12 Reflection-based processing of input parameters for commands Expired - Fee Related US7620959B2 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US10/438,234 US7620959B2 (en) 2003-05-12 2003-05-12 Reflection-based processing of input parameters for commands
EP04009697A EP1477897A3 (en) 2003-05-12 2004-04-23 Reflection-based processing of input parameters for commands
KR1020040032922A KR100995199B1 (en) 2003-05-12 2004-05-11 Reflection-based processing of input parameters for commands
CNB2004100434914A CN100464294C (en) 2003-05-12 2004-05-12 Reflection-based processing of input parameters for commands
JP2004142832A JP4889204B2 (en) 2003-05-12 2004-05-12 Medium and system for processing input parameters of commands to shell
US10/883,492 US7624401B2 (en) 2003-05-12 2004-06-30 Reflection-based processing of input parameters for commands

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/438,234 US7620959B2 (en) 2003-05-12 2003-05-12 Reflection-based processing of input parameters for commands

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/883,492 Continuation US7624401B2 (en) 2003-05-12 2004-06-30 Reflection-based processing of input parameters for commands

Publications (2)

Publication Number Publication Date
US20040230987A1 US20040230987A1 (en) 2004-11-18
US7620959B2 true US7620959B2 (en) 2009-11-17

Family

ID=33029805

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/438,234 Expired - Fee Related US7620959B2 (en) 2003-05-12 2003-05-12 Reflection-based processing of input parameters for commands
US10/883,492 Expired - Fee Related US7624401B2 (en) 2003-05-12 2004-06-30 Reflection-based processing of input parameters for commands

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/883,492 Expired - Fee Related US7624401B2 (en) 2003-05-12 2004-06-30 Reflection-based processing of input parameters for commands

Country Status (5)

Country Link
US (2) US7620959B2 (en)
EP (1) EP1477897A3 (en)
JP (1) JP4889204B2 (en)
KR (1) KR100995199B1 (en)
CN (1) CN100464294C (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130179152A1 (en) * 2012-01-11 2013-07-11 Siemens Aktiengesellschaft Computer Implemented Method, Apparatus, Network Server And Computer Program Product
US20140029053A1 (en) * 2012-07-27 2014-01-30 Kyocera Document Solutions Inc. Data transmission device and image forming apparatus including same
US9843559B2 (en) * 2004-06-08 2017-12-12 Naver Corporation Method for determining validity of command and system thereof

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7356390B2 (en) 1999-06-29 2008-04-08 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
WO2002087112A2 (en) 2001-04-18 2002-10-31 Space Data Corporation Unmanned lighter-than-air safe termination and recovery methods
US9632503B2 (en) 2001-04-18 2017-04-25 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US9908608B2 (en) 2001-04-18 2018-03-06 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US9643706B2 (en) 2001-04-18 2017-05-09 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US7130893B2 (en) 2003-05-19 2006-10-31 International Business Machines Corporation System and method for representing MFS control blocks in XML for MFS-based IMS applications
US7421701B2 (en) 2002-09-16 2008-09-02 International Business Machines Corporation System for facilitating transactions between thin-clients and message format service (MFS)-based information management system (IMS) applications
US7370280B2 (en) 2003-09-23 2008-05-06 International Business Machines Corporation Apparatus, system, and method for defining a web services interface for MFS-based IMS applications
US7594170B2 (en) * 2003-10-24 2009-09-22 Microsoft Corporation Mechanism for providing data driven command line output
US7676798B2 (en) * 2003-10-24 2010-03-09 Microsoft Corporation Mechanism for obtaining and applying constraints to constructs within an interactive environment
US20050091424A1 (en) * 2003-10-24 2005-04-28 Snover Jeffrey P. Mechanism for analyzing partially unresolved input
US7418508B2 (en) 2004-01-26 2008-08-26 International Machines Corporation System and method to facilitate XML enabled IMS transactions between a remote client and an IMS application program
US7617459B2 (en) * 2004-01-28 2009-11-10 International Business Machines Corporation Apparatus, system, and method for automatically generating a web interface for an MFS-based IMS application
US7503038B2 (en) * 2004-08-27 2009-03-10 Microsoft Corporation System and method for seamlessly comparing objects
US20060117354A1 (en) * 2004-11-29 2006-06-01 Mark Schutte Consolidating video-on-demand (VOD) services with multi-room personal video recording (MR-PVR) services
US8566806B2 (en) * 2005-03-04 2013-10-22 Microsoft Corporation Command-line data-type discovery and conversion
EP1866780A4 (en) 2005-03-30 2013-07-31 Welch Allyn Inc Communication of information between a plurality of network elements
US7716252B2 (en) * 2005-07-29 2010-05-11 Microsoft Corporation Dynamically exposing relationships among entities contained in data stores
US7587385B2 (en) * 2005-08-30 2009-09-08 Sap Ag Autocompletion for unordered lists
US8473971B2 (en) 2005-09-06 2013-06-25 Microsoft Corporation Type inference and type-directed late binding
US7567257B2 (en) 2005-12-16 2009-07-28 Microsoft Corporation Partition-based undo of partitioned object graph
US7818726B2 (en) 2006-01-25 2010-10-19 Microsoft Corporation Script-based object adaptation
US20070174823A1 (en) * 2006-01-25 2007-07-26 Microsoft Corporation Compile-time interpretable code error detection
US20080127072A1 (en) * 2006-09-07 2008-05-29 Sun Microsystems, Inc. Method and system for extending evaluation for intermediate representation interpretation
US7720868B2 (en) * 2006-11-13 2010-05-18 Microsoft Corporation Providing assistance with the creation of an XPath expression
US8005671B2 (en) * 2006-12-04 2011-08-23 Qualcomm Incorporated Systems and methods for dynamic normalization to reduce loss in precision for low-level signals
US20080155565A1 (en) * 2006-12-20 2008-06-26 International Business Machines Corporation Automatic Completion of Command Line Arguments
US20080320453A1 (en) * 2007-06-21 2008-12-25 Microsoft Corporation Type inference and late binding
US8321836B2 (en) * 2007-06-21 2012-11-27 Microsoft Corporation Late bound programmatic assistance
US9043727B2 (en) * 2007-07-26 2015-05-26 Microsoft Technology Licensing, Llc Visualization techniques for imprecise statement completion
US8209356B1 (en) * 2008-01-14 2012-06-26 Marvell International Ltd. Direct command line parser
US8224997B2 (en) * 2009-02-23 2012-07-17 International Business Machines Corporation Document source debugger
KR101158534B1 (en) * 2009-09-21 2012-06-21 자바정보기술 주식회사 A dynamic process management system for processing data in various environment
US8572591B2 (en) 2010-06-15 2013-10-29 Microsoft Corporation Dynamic adaptive programming
US8731902B2 (en) * 2010-12-23 2014-05-20 Sap Ag Systems and methods for accessing applications based on user intent modeling
US9256401B2 (en) 2011-05-31 2016-02-09 Microsoft Technology Licensing, Llc Editor visualization of symbolic relationships
MX2017008552A (en) 2014-12-24 2018-03-15 Space Data Corp Techniques for intelligent balloon/airship launch and recovery window location.
WO2016105522A1 (en) 2014-12-24 2016-06-30 Space Data Corporation Breaking apart a platform upon pending collision
US10059421B2 (en) 2014-12-30 2018-08-28 Space Data Corporation Multifunctional balloon membrane
US10545737B2 (en) * 2017-06-13 2020-01-28 Microsoft Technology Licensing, Llc Model binding for command line parsers
US20190004821A1 (en) * 2017-06-29 2019-01-03 Microsoft Technology Licensing, Llc Command input using robust input parameters
US10719340B2 (en) 2018-11-06 2020-07-21 Microsoft Technology Licensing, Llc Command bar user interface
CN112256355B (en) * 2020-12-24 2021-05-11 完美世界(北京)软件科技发展有限公司 Data-driven system function loading method, equipment and storage medium
CN115496648B (en) * 2022-11-16 2023-03-21 摩尔线程智能科技(北京)有限责任公司 Management method, management device and management system of graphics processor

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5450600A (en) * 1991-11-08 1995-09-12 Mitsubishi Denki Kabushiki Kaisha Integrated command recognition apparatus and method for selecting an optimal command among numerous commands
US5845300A (en) * 1996-06-05 1998-12-01 Microsoft Corporation Method and apparatus for suggesting completions for a partially entered data item based on previously-entered, associated data items
US6266666B1 (en) * 1997-09-08 2001-07-24 Sybase, Inc. Component transaction server for developing and deploying transaction- intensive business applications
US6286035B1 (en) * 1999-02-01 2001-09-04 Lucent Technologies Inc. Validating and parsing engine for system configuration and support command messages
US20010052030A1 (en) 1999-12-14 2001-12-13 Nobuhisa Shiraishi Command processing apparatus
US6334158B1 (en) * 1996-11-29 2001-12-25 Agilent Technologies, Inc. User-interactive system and method for integrating applications
US6405365B1 (en) * 1999-07-02 2002-06-11 Cisco Technology, Inc. Computer program command generator and parser
US20020087408A1 (en) * 1999-06-25 2002-07-04 Burnett Jonathan Robert System for providing information to intending consumers
US6724408B1 (en) * 1999-08-10 2004-04-20 International Business Machines Corporation Command line interface for a data processing system
US6871283B1 (en) * 1990-02-13 2005-03-22 Hewlett-Packard Development Company, L.P. Processing trusted commands in trusted and untrusted environments
US6907572B2 (en) * 2001-08-10 2005-06-14 Occam Networks Command line interface abstraction engine
US20070074324P1 (en) 2005-09-26 2007-03-29 Sunny Osteospermum Aps Osteospermum plant named 'sunny marina'

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1184828C (en) * 2001-08-10 2005-01-12 华为技术有限公司 Method for implementing simultaneously supporting two style command line configuration

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6871283B1 (en) * 1990-02-13 2005-03-22 Hewlett-Packard Development Company, L.P. Processing trusted commands in trusted and untrusted environments
US5450600A (en) * 1991-11-08 1995-09-12 Mitsubishi Denki Kabushiki Kaisha Integrated command recognition apparatus and method for selecting an optimal command among numerous commands
US5845300A (en) * 1996-06-05 1998-12-01 Microsoft Corporation Method and apparatus for suggesting completions for a partially entered data item based on previously-entered, associated data items
US6334158B1 (en) * 1996-11-29 2001-12-25 Agilent Technologies, Inc. User-interactive system and method for integrating applications
US6266666B1 (en) * 1997-09-08 2001-07-24 Sybase, Inc. Component transaction server for developing and deploying transaction- intensive business applications
US6286035B1 (en) * 1999-02-01 2001-09-04 Lucent Technologies Inc. Validating and parsing engine for system configuration and support command messages
US20020087408A1 (en) * 1999-06-25 2002-07-04 Burnett Jonathan Robert System for providing information to intending consumers
US6405365B1 (en) * 1999-07-02 2002-06-11 Cisco Technology, Inc. Computer program command generator and parser
US6724408B1 (en) * 1999-08-10 2004-04-20 International Business Machines Corporation Command line interface for a data processing system
US20010052030A1 (en) 1999-12-14 2001-12-13 Nobuhisa Shiraishi Command processing apparatus
US6907572B2 (en) * 2001-08-10 2005-06-14 Occam Networks Command line interface abstraction engine
US20070074324P1 (en) 2005-09-26 2007-03-29 Sunny Osteospermum Aps Osteospermum plant named 'sunny marina'

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
"CLIM: 27 Command Processing", retrieved on Feb. 13, 2007, at >, pp. 1-11.
"Generic Command Line Parser", IBM Corporation,vol. 37, No. 05, 1994, pp. 55-58.
"Internet Archive Wayback Marchine", retrieved on Feb. 13, 2007, at >, pp. 1.
"Validation of Parameter Subsets in Commands", IBM Corporation, vol. 37, No. 06B, 1994, pp. 585-587.
Conway, Declarative Command-line Interfaces, School of Computer Science and Software Engineering, Monach University, 1998, pp. 1-13. *
Jones, Parse and Validate command Line Parameters with VB.Net, Devx.com, Dec. 4, 2002, pp. 1-6. *
Lawrence, jcmdline Package User Guide Release 1.0.1, sourceforge.net, Dec. 13, 2002, pp. 1-9. *
Lawrence, jcmdline Pakcage User Guide Release 1.0.3, Oct. 29, 2002, pp. 1-10. *
Mckay, "CLIM: The Common Lisp Interface Manager", Communications of the ACM, vol. 34, No. 9, 1991, pp. 58-59.

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9843559B2 (en) * 2004-06-08 2017-12-12 Naver Corporation Method for determining validity of command and system thereof
US20130179152A1 (en) * 2012-01-11 2013-07-11 Siemens Aktiengesellschaft Computer Implemented Method, Apparatus, Network Server And Computer Program Product
US20140029053A1 (en) * 2012-07-27 2014-01-30 Kyocera Document Solutions Inc. Data transmission device and image forming apparatus including same
US8964229B2 (en) * 2012-07-27 2015-02-24 Kyocera Document Solutions Inc. Data transmitting device and image forming apparatus which process and transmit data according to command information and destination address identified from symbol sequence inputted at the time of the transmission

Also Published As

Publication number Publication date
EP1477897A3 (en) 2007-04-11
KR100995199B1 (en) 2010-11-17
US20050004973A1 (en) 2005-01-06
JP2004342108A (en) 2004-12-02
US7624401B2 (en) 2009-11-24
CN1550982A (en) 2004-12-01
EP1477897A2 (en) 2004-11-17
US20040230987A1 (en) 2004-11-18
JP4889204B2 (en) 2012-03-07
KR20040097909A (en) 2004-11-18
CN100464294C (en) 2009-02-25

Similar Documents

Publication Publication Date Title
US7620959B2 (en) Reflection-based processing of input parameters for commands
US8230405B2 (en) Administrative tool environment
US7536696B2 (en) Mechanism for handling input parameters
US7587670B2 (en) Mechanism for providing data driven command line output
US7640540B2 (en) Mechanism for providing extended functionality to command line instructions
US7676798B2 (en) Mechanism for obtaining and applying constraints to constructs within an interactive environment
AU2004279192B2 (en) Mechanism for analyzing partially unresolved input

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SNOVER, JEFFREY P.;TRUHER, JAMES W. III;WRAY, DARYL W.;AND OTHERS;REEL/FRAME:014082/0498;SIGNING DATES FROM 20030418 TO 20030511

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0477

Effective date: 20141014

FPAY Fee payment

Year of fee payment: 8

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20211117