Re: Ada.Command_Line and wildcards

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> 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 :).


Hi Georg, 

As long as your arguments are heavily based on your experience and
practice we have to talk about what you're doing or we can stop
discussing.



> 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.)

Most (auto-) configuration concepts are really bad hacks. They are
hardly Unix design choices. The wrong place to fix that is to change
the shell or the prcess model. The right way to do it, is, to rethink
the way one produces platform specific sources from the common source
corpus.


> 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.

Really bad practice (shared accounts, changing definition of known
names) does not make a good argument against Unix design choices.

> Having to debug shell setups isn't an argument in favor of typical
> Unix environments in my book, in particular if these are "immutable"

No. I want to be able to define short cuts in MY account. And I want
to be able to change setups in a controlled way, since it make a
difference in which toolset/world I'm working -- and sometimes one
needs multiple (conflicting) toolset at the same machine.

> system settings. But these seem to be the new Unix hackers' favorites.

new Unix hacker?

Regards -- Markus