Re: Excercices

From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 10/15/04 

Date: Fri, 15 Oct 2004 10:16:45 +0200

"T.M. Sommers" wrote:
> Herbert Kleebauer wrote:
> > Phil Carmody wrote:
> >
> >>The shell's job is to pass parameters to a program.
> >>That's the end of the story.
> >
> > No, the shell has to pass the information given on the
> > command line to the program. Maybe lazy programmer
> > prefer a preprocessing of this information by the shell,
> > but if you want full control, then this is not acceptable.
>
> It has nothing to do with laziness, but with efficiency,
> uniformity across applications, and just plain common sense. It
> is silly to force every program to do its own globbing when that
> job can be done in one place.

Why is it more efficient when the code is executed as part
of the shell program instead as a part of the user program?
Or are you not speaking about efficiency regarding to code execution
but to programming. You don't have to write this code yourself,
Microsoft has done this already. This has the advantage that you
really get a system wide uniformity and not only for one of
many shells.

  Expanding Wildcard Arguments

  Microsoft Specific >

  When running a C program, you can use either of the two wildcards the
  question mark (?) and the asterisk (*) to specify filename and path
  arguments on the command line.

  Command-line arguments are handled by a routine called _setargv (or
  _wsetargv in the wide-character environment), which by default does
  not expand wildcards into separate strings in the argv string array.
  You can replace the normal _setargv routine with a more powerful version
  of _setargv that does handle wildcards by linking with the Setargv.obj
  file. If your program uses a wmain function, link with Wsetargv.obj.

  To link with Setargv.obj or Wsetargv.obj, use the /link option. For example:

  cl typeit.c /link setargv.obj

  The wildcards are expanded in the same manner as operating system commands.
  (See your operating system users guide if you are unfamiliar with wildcards.)
  Enclosing an argument in double quotation marks (" ") suppresses the wildcard
  expansion. Within quoted arguments, you can represent quotation marks literally
  by preceding the double-quotation-mark character with a backslash (\). If no
  matches are found for the wildcard argument, the argument is passed literally.

  END Microsoft Specific

Relevant Pages

  • Re: -R switch in rm command doesnt...
    ... Few Unix commands understand wildcards. ... expanded in the shell before the command has run. ... To delete files matching the pattern *.cmeta from this all subdirectories, ... The quotes around the *.cmeta are important - they stop the shell ...
    (uk.comp.os.linux)
  • Re: exec(cmdArray) to bash shell does not work
    ... Wildcards are a shell function. ... This forces the BASH shell to execute the command, ...
    (comp.lang.java)
  • Re: The POSIX and GNU definitions of find -exec
    ... The syntax of find (or any other command) does *not* depend on ... whether you run it through the shell or from another C program. ... If you type "somecommand a b;" at the shell prompt, ... It's like that for wildcards too, ...
    (comp.unix.shell)
  • Re: shit
    ... Wildcards are expanded by the shell before passing them to the command. ...
    (comp.unix.shell)
  • Bash-4.0 available for FTP
    ... Unlike previous bash distributions, this tar file includes the formatted ... The shell has been changed to be more ... rigorous about parsing commands inside command substitutions, ... Changes have been made to the Readline library being released at ...
    (gnu.announce)