From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,e219d94b946dfc26
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Ada.Command_Line and wildcards
From: Georg Bauhaus <bauhaus@futureapps.de>
In-Reply-To: <sa41wk4sdkp.fsf@margay.local>
References: <45dcaed8_6@news.bluewin.ch>
	 <C2026327.9876A%yaldnif.w@blueyonder.co.uk>
	 <1172132169.423514.271890@s48g2000cws.googlegroups.com>
	 <545bgvF1ttrphU1@mid.individual.net>
	 <1495406.QZvfpqijrQ@linux1.krischik.com>
	 <6dy7mn3hhu.fsf@hod.lan.m-e-leypold.de>
	 <1172328891.5496.62.camel@localhost.localdomain>
	 <sa41wk4sdkp.fsf@margay.local>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID: <1173096982.3712.37.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Date: Mon, 05 Mar 2007 13:16:22 +0100
Organization: Arcor
NNTP-Posting-Date: 05 Mar 2007 13:13:24 CET
NNTP-Posting-Host: 587c9dc9.newsspool1.arcor-online.net
X-Trace: 
 DXC=FVG4`Od04X8^cW`WBF>WQ<ic==]BZ:af>4Fo<]lROoR1Fl8W>\BH3Y2LhEEVY^Hne9N[W<lHX`=B4\6BhD5G6\i<:JO^g4hSfV1
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:9676
Date: 2007-03-05T13:13:24+01:00
List-Id: <comp.lang.ada>

On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
>     Georg> $ echo *.ads
> 
> Get a real shell !

Sure. Point is, we had been talking about Unix design choices
not about what I am seemingly doing (doing according to you
and others, that is, which is not what I'm doing :).

Many essential shell scripts are built around Unix shell details.
E.g. software configuration scripts tend to stubbornly use a mix
of bash (sic, not sh, not ksh, not SUN sh), m4, sed, C helpers,
etc etc. In particular, they require the Unix process model.

See the current difficulties in translating recent GCC in a
MinGW environment.

Suppose you want to port some piece of Unix software to some other
system, a text processing tool, say. The C source is in fact
perfectly portable ANSI C. But it can be real hard to get the C source
through the configure stage only because configuration _depends_
on original style Unix shells and the Unix process model (e.g. piped
processes "within" a backtick (yes, I know $(), not the point), result
to be assigned to some variable. The GNU "standard" config.guess is
such a thing.)

On occasions like these the choice of a shell matters. It is less
relevant what you or I would choose, because we don't have a choice!
(Other than occasionally ask the developers to consider the
consequences of a larger Unix dependence graph when they claim
their program is portable to non-Unix systems.)

> or set NULLGLOB:
> 
> > setopt NULLGLOB
> > echo *.ads

Yes, certainly. Now for contrast, if I log into a system where
I participate in a *shared* account and where system defaults *must*
not be changed, and find a huge list of predefined aliases.
I wasn't amused once when I found out that "unzip" was an alias,
setting a number of options. And yes, I know how to disable aliases.
Having to debug shell setups isn't an argument in favor of typical
Unix environments in my book, in particular if these are "immutable"
system settings. But these seem to be the new Unix hackers' favorites.